> On 07 Nov 2015, at 16:22, Aaron Zauner <[email protected]> wrote: > > Hi, > > L. Aaron Kaplan wrote: >> First of all, thank you very much for checking! This is really what keeps >> the project useful! >> People checking the assumptions and the document. >> Thanks! > > +1. Thanks! > >> >> To answer your question: >> >> IMHO we should stick with the original and make sure that it’s consistently >> the same everywhere. >> This was the idea when we created the guide. > > I agree there. I remember there being some exceptions though - a few > daemons were restricted in how they parsed cipherstrings passed from > config files.
Yes. > >> >> I remember I once wrote a simple sed script to search and replace the string >> “@@@CIPHERSTRINGB@@@“ in every .tex file with the actual value. >> I believe we should quickly move back to such a search & replace mechanism >> in order to keep the document consistent. That’s important. >> [1] > > We since split the document into more parts (i.e. files) and have a > dedicated directory (`src/configuration`) that holds actual config files > instead of inlining those in the document itself. Tobias Pape has done a > tremendous effort there. > > These config files are currently not auto generated and do *not* contain > the macro you mention above. So a simple `git grep '@@@CIPHERSTRINGB@@@' > *` in the config dir won't yield any results currently. > As I said before - we *had* that. It got commited-over ;-) > If we choose to autogenerate those, they really should be checked with > some form of continuous integration tooling (jenkins, travis-ci, etc.) > and some form of linting. > Agreed. >> On the other hand - you are right - there are differences in different >> OSes/libraries (openssl versions) and clients. >> For that we had discussed that the best option would be an automatic testing >> facility which tests compatibilities. >> There seems to be some previous work on this from azet as well as others. >> Once these test results are in, we *could* make a cipher string generator on >> the web page where users can select the OS version, libraries , supported >> clients and click on “Variant A: a super secure cipher string, no >> compatibility” or “Variant B: compatible secure cipher string”. >> > > Somebody still needs to do this, nobody volunteered so far. It's a lot > of work if we're going to integrate testing. Well, then it’s time to re-activate our group. > >> [1] (and if anyone wants to git blame… we can figure out how these >> inconsistencies slipped in, but I do not assume malicious intent. I’d rather >> assume this happens by accident when multiple people contribute). > > Just checked the git log etc and there's no malicious activity, it’s That’s what I thought as well. best, a.
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Ach mailing list [email protected] http://lists.cert.at/cgi-bin/mailman/listinfo/ach
