Re: [cryptography] openssl on git
You know other source control systems, and presumably git also, have an excludes list which can contain wildcards. It comes prepopulated with eg *.o - as you probably dont want to check them in. I think you could classify this as a git bug (or more probably a mistake in how github are using/configuring git) that it doesnt exclude checking in .ssh and maybe some of the .ssh exclusive related extensions. I say this because its not like ssh is some strange third party app with unknown extension: git and cvs, cvn etc all directly rely on ssh and have various things about ssh baked into them. (The user can always override or change if he really wants to do check in .ssh on a private heavily guarded repo or because hes using it for test keys only etc). Adam On Sun, Jan 27, 2013 at 09:36:44PM -0500, Eitan Adler wrote: On 27 January 2013 21:34, Patrick Mylund Nielsen cryptogra...@patrickmylund.com wrote: I don't understand how you can accidentally check in ~/.ssh to your repository, or at least not notice afterwards. Hopefully the OpenSSL authors won't do that! If you keep ~ in a git repo it is surprisingly easy ;) -- Eitan Adler ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] openssl on git
AB == Adam Back a...@cypherspace.org writes: AB You know other source control systems, and presumably git also, have AB an excludes list which can contain wildcards. It comes prepopulated AB with eg *.o - as you probably dont want to check them in. For git, the file is called .gitignore. You can add one in any directory in the repo; each file covers that dir and each child dir, and the syntax provides for overriding parent ignores. Git also support per-clone $GIT_DIR/info/exclude and per-user ignore files. Cf gitignore(1). AB I think you could classify this as a git bug (or more probably a AB mistake in how github are using/configuring git) that it doesnt AB exclude checking in .ssh and maybe some of the .ssh exclusive AB related extensions. There is nothing wrong with using git -- or any other vcs -- to backup one's $HOME. What is arguably dumb is storing that backup on a public site. *Any* public site. And unencrypted at that. This seems to be another case of thoughtless everything to the cloud (said with a Q♥-off-with-their-heads sort of tone). ;^/ I'm pretty sure hg and bzr also require the repo to specify what to ignore. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] openssl on git
To rephrase, I don't understand why anyone would push their /home/user / backup git repository to a public one on GitHub :) On Mon, Jan 28, 2013 at 3:49 AM, ianG i...@iang.org wrote: On 28/01/13 05:36 AM, Eitan Adler wrote: On 27 January 2013 21:34, Patrick Mylund Nielsen cryptography@patrickmylund.**com cryptogra...@patrickmylund.com wrote: I don't understand how you can accidentally check in ~/.ssh to your repository, or at least not notice afterwards. Hopefully the OpenSSL authors won't do that! If you keep ~ in a git repo it is surprisingly easy ;) Which a lot of developers do for backups. iang __**_ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/**mailman/listinfo/cryptographyhttp://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] openssl on git
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/27/2013 09:34 PM, Patrick Mylund Nielsen wrote: I don't understand how you can accidentally check in ~/.ssh to your repository, or at least not notice afterwards. Hopefully the OpenSSL authors won't do that! There are people who set up personal Git repositories on Github for their configuration files (in /etc, ~/.config, and apparently sometimes ~/.ssh). Some seem to do a `git add .ssh/*` without stopping to think about what might be in there aside from a config file. - -- The Doctor [412/724/301/703] [ZS|Media] Developer, Project Byzantium: http://project-byzantium.org/ PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1 WWW: https://drwho.virtadpt.net/ You can't condemn an entire species. --Ganthet -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlEGncQACgkQO9j/K4B7F8Ee6wCgsTivnv2ZJZRUU+ZrEuJouyBf hYoAnAnvwlrHRpho1hfpPbUbl4vXhaH6 =Z+zH -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] openssl on git
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/28/2013 10:24 AM, Patrick Mylund Nielsen wrote: To rephrase, I don't understand why anyone would push their /home/user / backup git repository to a public one on GitHub :) For the use case of personal config files, it makes setting up one's preferred environment across multiple machines easier. One can check out their customized /.*rc/ files, their desktop customizations, and other such things instead of recreating the config files by hand. I do this with the contents of my ~/.config/backpac/hostname/ directories on my Arch Linux machines, because I can do a bare-bones install and then use Backpac to deploy my laptop package list, my workstation package list, my server package list, et cetera without having to leaf through a number of notebooks to figure out what package names I need to start installing. So long as the user does not do something dumb, like including crypto keys in the repository, chances are most-but-probably-not-all of the contents of those repos are not sensitive, so the user probably cares little about making their personal settings for their text editor of choice public. - -- The Doctor [412/724/301/703] [ZS|Media] Developer, Project Byzantium: http://project-byzantium.org/ PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1 WWW: https://drwho.virtadpt.net/ You can't condemn an entire species. --Ganthet -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlEGn2AACgkQO9j/K4B7F8ESLwCfawDP0WGKg1f3bMu3nG8wJjwO jmQAn36M+wNZKsuvUM3ABefogmacdJ/q =ehmt -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] openssl on git
offtopic to list purpose, but perhaps timely to this thread http://www.webmonkey.com/2013/01/users-scramble-as-github-search-exposes-passwords-security-details/ --dan ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] openssl on git
I don't understand how you can accidentally check in ~/.ssh to your repository, or at least not notice afterwards. Hopefully the OpenSSL authors won't do that! On Sun, Jan 27, 2013 at 9:29 PM, d...@geer.org wrote: offtopic to list purpose, but perhaps timely to this thread http://www.webmonkey.com/2013/01/users-scramble-as-github-search-exposes-passwords-security-details/ --dan ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] openssl on git
On 27 January 2013 21:34, Patrick Mylund Nielsen cryptogra...@patrickmylund.com wrote: I don't understand how you can accidentally check in ~/.ssh to your repository, or at least not notice afterwards. Hopefully the OpenSSL authors won't do that! If you keep ~ in a git repo it is surprisingly easy ;) -- Eitan Adler ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] openssl on git
On Tue, Jan 1, 2013 at 1:02 PM, Ben Laurie b...@links.org wrote: We're experimenting with moving openssl to git. Again. We've tried an import using cvs2git - does anyone have any views on better tools? You can see the results here (not all branches pushed to github yet, let me know if there's a particular branch you'd like me to add): https://github.com/benlaurie/openssl. Any comments? Would you consider adding a hook to git (assuming it include the ability). Have the hook replace tabs with white space. This is necessary because different editors render tabs in different widths. So white space makes thing consistent for everyone. Then have the hook format the source code against some standard. I don't care which, as long as its consistent. Jeff ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] openssl on git
On 8 January 2013 18:06, Jeffrey Walton noloa...@gmail.com wrote: On Tue, Jan 1, 2013 at 1:02 PM, Ben Laurie b...@links.org wrote: We're experimenting with moving openssl to git. Again. We've tried an import using cvs2git - does anyone have any views on better tools? You can see the results here (not all branches pushed to github yet, let me know if there's a particular branch you'd like me to add): https://github.com/benlaurie/openssl. Any comments? Would you consider adding a hook to git (assuming it include the ability). Have the hook replace tabs with white space. This is necessary because different editors render tabs in different widths. So white space makes thing consistent for everyone. Then have the hook format the source code against some standard. I don't care which, as long as its consistent. Funnily enough we've been discussing this. The problem is that the vast majority of the code is formatted to look OK with pure tab indentation. Which means that with tabs set to a standard 8 columns it sucks (though that does appear to be what was used in the original code base). People are reluctant to change _all_ the code for the sake of indentation and so the current favourite option is to adopt a code style that works with different tab widths (specifically 4 and 8 column) and use no spaces. I realise that almost no-one works this way, but it does seem like a sensible option in this case. I would certainly like to have an agreed style that is consistent. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] openssl on git
On Tue, Jan 8, 2013 at 1:21 PM, Ben Laurie b...@links.org wrote: On 8 January 2013 18:06, Jeffrey Walton noloa...@gmail.com wrote: On Tue, Jan 1, 2013 at 1:02 PM, Ben Laurie b...@links.org wrote: We're experimenting with moving openssl to git. Again. We've tried an import using cvs2git - does anyone have any views on better tools? You can see the results here (not all branches pushed to github yet, let me know if there's a particular branch you'd like me to add): https://github.com/benlaurie/openssl. Any comments? Would you consider adding a hook to git (assuming it include the ability). Have the hook replace tabs with white space. This is necessary because different editors render tabs in different widths. So white space makes thing consistent for everyone. Then have the hook format the source code against some standard. I don't care which, as long as its consistent. Funnily enough we've been discussing this. The problem is that the vast majority of the code is formatted to look OK with pure tab indentation. Which means that with tabs set to a standard 8 columns it sucks (though that does appear to be what was used in the original code base). I [respectfully] think the fallacy is standard 8 columns. Two problems: (1) I use either 4 columns or 2 columns on occasion. (2) I'm not aware of editors adhering to such standards (gedit vs emacs vs visual Studio vs Xcode vs Notepad vs ). They all seem to get white space correct, though. People are reluctant to change _all_ the code for the sake of indentation and so the current favourite option is to adopt a code style that works with different tab widths (specifically 4 and 8 column) and use no spaces. I realise that almost no-one works this way, but it does seem like a sensible option in this case. Again, spaces are known and every editor gets them right. I would certainly like to have an agreed style that is consistent. Yes, I'm not making any recommendations. Let the Dev Team choose what they want amongst themselves, and then do it consistently. The git plug-in will ensure its applied consistently without prejudice. Jeff ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] openssl on git
On 1/8/2013 1:21 PM, Ben Laurie wrote: On 8 January 2013 18:06, Jeffrey Walton noloa...@gmail.com wrote: Would you consider adding a hook to git (assuming it include the ability). Have the hook replace tabs with white space. This is necessary because different editors render tabs in different widths. So white space makes thing consistent for everyone. Then have the hook format the source code against some standard. I don't care which, as long as its consistent. Git does support hooks but any hook that modifies the patchset must be executed on the system that performs the commit to the local repository. Otherwise the sha1 of the patch in the local repository does not match the commit in the remote repository. What you can do is apply a hook in the upstream repository that rejects patches that fail various tests. OpenAFS uses Gerrit as a patch review system. One of the benefits of Gerrit is that it highlights whitespace errors. Our policy is that patches submitted to Gerrit will fail review if the formatting is incorrect. We block patchsets ending up in the repository via that manner. Funnily enough we've been discussing this. The problem is that the vast majority of the code is formatted to look OK with pure tab indentation. Which means that with tabs set to a standard 8 columns it sucks (though that does appear to be what was used in the original code base). People are reluctant to change _all_ the code for the sake of indentation and so the current favourite option is to adopt a code style that works with different tab widths (specifically 4 and 8 column) and use no spaces. I realise that almost no-one works this way, but it does seem like a sensible option in this case. I would certainly like to have an agreed style that is consistent. OpenAFS has performed various code formatting cleanups over the years across the entire code base. The major downside of such efforts is that git pickaxe or git blame should less meaningful output because the entire tree has been altered. However, openssl is in the process of converting the repository from cvs to git. One of the things that could be done in the process is to reformat each patchset from cvs before committing it to git. This would ensure the history is maintained while also ensuring format consistency across the tree. Jeffrey Altman signature.asc Description: OpenPGP digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] openssl on git
On Tue, Jan 8, 2013 at 12:06 PM, Jeffrey Walton noloa...@gmail.com wrote: Would you consider adding a hook to git (assuming it include the ability). Have the hook replace tabs with white space. This is necessary because different editors render tabs in different widths. So white space makes thing consistent for everyone. Hooks shouldn't modify the commit, just accept or reject. Nico -- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] openssl on git
On Tue, Jan 8, 2013 at 9:30 PM, Nico Williams n...@cryptonector.com wrote: On Tue, Jan 8, 2013 at 12:06 PM, Jeffrey Walton noloa...@gmail.com wrote: Would you consider adding a hook to git (assuming it include the ability). Have the hook replace tabs with white space. This is necessary because different editors render tabs in different widths. So white space makes thing consistent for everyone. Hooks shouldn't modify the commit, just accept or reject. Thanks Nico. Out of curiosity: what does one typically do when there's a standard policy to enforce? I [personally] would not reject a check-in for whitespace (I would reject for many other reasons, though - such as CompSci 101 omissions). Perhaps allow the check-in to proceed unmolested, and then have a second process run after the commit to perform policy enforcement (for example, whitespace or coding style). In this scenario, would the second process perform a second commit? Jeff ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] openssl on git
On 9 January 2013 00:08, Jeffrey Walton noloa...@gmail.com wrote: On Tue, Jan 8, 2013 at 9:30 PM, Nico Williams n...@cryptonector.com wrote: On Tue, Jan 8, 2013 at 12:06 PM, Jeffrey Walton noloa...@gmail.com wrote: Would you consider adding a hook to git (assuming it include the ability). Have the hook replace tabs with white space. This is necessary because different editors render tabs in different widths. So white space makes thing consistent for everyone. Hooks shouldn't modify the commit, just accept or reject. Thanks Nico. Out of curiosity: what does one typically do when there's a standard policy to enforce? I [personally] would not reject a check-in for whitespace (I would reject for many other reasons, though - such as CompSci 101 omissions). The standard policy is usually enforced via post-commit code review lots of yelling or via commit hooks which look for specific indicators and reject the commit if they fail. Perhaps allow the check-in to proceed unmolested, and then have a second process run after the commit to perform policy enforcement (for example, whitespace or coding style). In this scenario, would the second process perform a second commit? this can break git blame. I prefer a manual tool make fixlint or the like which does the whitespace fixes. -- Eitan Adler ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] openssl on git
On Tue, Jan 8, 2013 at 11:08 PM, Jeffrey Walton noloa...@gmail.com wrote: On Tue, Jan 8, 2013 at 9:30 PM, Nico Williams n...@cryptonector.com wrote: On Tue, Jan 8, 2013 at 12:06 PM, Jeffrey Walton noloa...@gmail.com wrote: Would you consider adding a hook to git (assuming it include the ability). Have the hook replace tabs with white space. This is necessary because different editors render tabs in different widths. So white space makes thing consistent for everyone. Hooks shouldn't modify the commit, just accept or reject. Thanks Nico. Out of curiosity: what does one typically do when there's a standard policy to enforce? I [personally] would not reject a check-in for whitespace (I would reject for many other reasons, though - such as CompSci 101 omissions). A number of projects I've worked on -particularly Solaris, but not only- absolutely reject pushes of code (and docs, and tests, and build goop) that fails style and other tests. Some even go so far as to trigger an incremental build to check that all is ok (but rarely is this done synchronously, and so build failures - email, possible backout, ...). Perhaps allow the check-in to proceed unmolested, and then have a second process run after the commit to perform policy enforcement (for example, whitespace or coding style). In this scenario, would the second process perform a second commit? Fast checks should be done synchronously and failure - push rejection. Slow checks should be done asynchronously and failure - nastygram. Slow check failures can be corrected in either of two ways: backout (mostly to be avoided, except when nearing releases or build milestones) or subsequent push to fix the issues. The more you can check quickly, the better: - *style (C style, Java style, JS style, ...) - referential integrity / software engineering process (commit references bug report, bug report is in correct state, if the bug report indicates that the fix should have docs impact then check that docs are updated, check that codereview has happened and the code has been signed off, or perhaps that code reviewers are listed, ...) Slower checks: - build - static bug analysis (including, for languages that need it, *lint) - tests Do all this, and your life will be easier. Every hour you put into writing checkers of this sort will pay for itself many times over for any sufficiently large project. Some such checkers can easily be found by searching around. The Solaris gate checks are, IIRC, in OpenSolaris and derivatives, for example, but I've seen others. Nico -- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] openssl on git
And, of course, *all* the gate checkers need to be available to the developer, so *they* can run them first. No trial and error please. (One quickly learns to code in the target upstream's style and other requirements.) ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] openssl on git
We're experimenting with moving openssl to git. Again. We've tried an import using cvs2git - does anyone have any views on better tools? You can see the results here (not all branches pushed to github yet, let me know if there's a particular branch you'd like me to add): https://github.com/benlaurie/openssl. Any comments? ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] openssl on git
* Ben Laurie: We're experimenting with moving openssl to git. Again. Nice. We've tried an import using cvs2git - does anyone have any views on better tools? Recently, I imported the OpenSSL repository with git cvsimport. It produced slightly corrupted results. CVS repositories as old as yours typically require manual tweaking of cvs2git because they contain traces of various CVS bugs. It might make sense to ask on the Git mailing list for help from someone who remembers previous conversions. This is not just about using the right tools, but requires rather arcane CVS knowledge. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] openssl on git
MM == Mantas Mikulėnas graw...@gmail.com writes: MM reposurgeon [1] may be helpful for cleaning up the conversion results. MM [1]: http://www.catb.org/esr/reposurgeon/ Also note that esr is in the process of updating all three of the cvs-git tools. His current code for cvs2git combined with the patch he posted today (on git@vger) for git's cvsimport might prove best. His other posts to git@vger over the past week or two give the best details. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
