[Ach] Apache, Dovecot and other Cipherstrings aren't matching CipherString-B

[L. Aaron Kaplan]

> On 07 Nov 2015, at 16:22, Aaron Zauner <azet at azet.org> 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.cert.at/pipermail/ach/attachments/20151107/ea952e27/attachment.sig>