I have a small portfolio site that I work on in my spare time as a way of demonstrating and applying what I have learned from school/work. Part of this demonstration involves me currently listing the repository as "public" on GitHub for anyone to see and browse. The reasoning behind this is that this means people can see how I approach project management and how I structure my code.

However, this introduces some security risks and other problems. Obviously, I now cannot include any private information, such as passwords of any kind (or private ports, mail variables, etc); rather, this needs to be moved elsewhere. For a while this was fine, until I decided that I wanted to include a blog, which necessitated users, which necessitates login functionality (whole new can of worms).

Because of this, I am now wondering where I can store all of the additional confidential information that I have created. Would I be better off to mark the repository as "private" and simply host some examples on my website? To me this is slightly less ideal, as it appears less authentic (ie. I might have spent additional time refactoring those files, above and beyond what I would typically do in my work).

However, is this something that would be a better idea in the long run, as well as simplifying development by consolidating my files?

UPDATE: The site uses almost no frameworks (other than Foundation 6 for front end markup) as this is the primary purpose of the site (to teach myself the concepts from the ground up).

Primary Question: Is there any benefit to hosting the site on a public repository that can't be gained by only exposing specific files elsewhere? i.e. in a Projects section of the site?

closed as primarily opinion-based by techraf, Arminius, Xander, Matthew, Julian Knight Jan 5 '17 at 20:28

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • How about hosting the demonstrations on some public hosting service and sharing the code for them on Github? – Limit Jan 5 '17 at 0:34
  • @Limit The portfolio site itself is hosted publicly and the code is already in a public repository on GitHub. I'm wondering if the public respository is a good idea. While it displays my code as is, it could lead to issues. – Kendall Jan 5 '17 at 0:37
  • This would then depend on the kind of code that you have for these applications. If you're wondering if there could be a hacker that could go through your public repository and then identify some vulnerability and exploit it, well always assume that it's a possibility. – Limit Jan 5 '17 at 0:39
  • Having said that, it's not a bad idea to show your code to the world especially if you are proud of it. Follow some secure coding practices and you should be able to succeed against a lot of hackers. – Limit Jan 5 '17 at 0:40
  • What about using a private branch for keeping sensitive data? – Serge Ballesta Jan 5 '17 at 10:39

We typically move sensitive information to configuration files with a name pattern, like every one of them ending in .conf extension, so you can simply create a .gitignore entry to match all of them across your project. Files matched according to .gitignore simply doesn't get pushed to the public repository, but you can continue working with them locally. If you want to be nice and allow others to test your application, provide example config files or documentation that contains the right format of data.

  • I have something similar to this already but then I don't have those files stored anywhere. So when developing from another system I have to recreate the file. Which is doable, but still annoying. Additionally, I'm wondering if exposing the way I do login logic is a bad idea, as it could potentially enable someone to have a much easier time attacking the site. – Kendall Jan 4 '17 at 23:30
  • 1
    If you have so many credentials that it gets difficult to handle, you can always make a credential server, from which you can request everything. Noone said that adding security makes your app code easier. – Rápli András Jan 4 '17 at 23:32
  • Btw, If you've done it right (used a framework nowadays), you can expose the login and everything. That means they will have to break a code that's continuously maintained and monitored. – Rápli András Jan 4 '17 at 23:34
  • I just updated the question to reflect that I use no frameworks (this is one of the purposes of the site) in order to learn the basis behind them. Which is why they will likely not be very secure (but I hopefully will be able to improve them). – Kendall Jan 4 '17 at 23:50

In general, it's considered an anti-pattern to include secrets in version control; at the least, it's agreed that if you store them, you do so in an encrypted format.

There are many options of software to facilitate this, but the list will change and get out of date easily, so it's best if you do your own research for specific tools. I would recommend that you first watch the talk Turtles All The Way Down for a longer overview than can fit here on the approaches to solving this problem and the downsides every approach has (namely, that you always need to provide another secret value).

For a while this was fine, until I decided that I wanted to include a blog, which necessiated users, which necessitates login functionality (whole new can of worms).

This isn't really true. Static site generators like Jekyll use git as the authorization mechanism (if you can commit, you can add posts). Additionally, authorization of external users for commenting is often handled via JavaScript-loaded commenting systems like Disqus.

  • The reason behind the quote you gave from my question is that using git as an authorization mechanism would defeat the purpose of learning by building from "nothing," as would using a system like Disqus. However, that would definitely be a good idea if it were the case. – Kendall Jan 6 '17 at 2:05
  • I'm not really a fan of re-implementing things that have already been written, but if you're going that route, you can write your own static site generator and/or commenting service. Of course, if you do the latter, you'll still have to handle dynamic user accounts, just in a different program, so that's probably not a terribly useful suggestion. The main part of my answer still holds, though, in that you shouldn't be tracking those secret values directly in the repository anyways, whether it's a public or private repo. – Xiong Chiamiov Jan 6 '17 at 3:04
  • Fair enough, I can definitely agree with that. And while I too do not recommende rewriting what has been written, I felt that doing it at a somewhat "simple" level would greatly increase my understanding of how other services work, and that has definitely been fulfilled. – Kendall Jan 6 '17 at 3:08

Not the answer you're looking for? Browse other questions tagged or ask your own question.