[Ach] CIPHERSTRINGB macro in config files

[L. Aaron Kaplan]

Dear Oliver,

please feel free to propose a patch for this.

Some background info (for the list):

Somehow, the @@CIPHERSTRING@@ macro slipped out from the code base. I agree with Tobias, that it does not make sense to have it directly in the config files, but the sed/awk/perl option for generating the config files sounds very reasonable.

The reason why we had the @@CIPHERSTRING@@ macro in the first place (as sed -i replacement BTW) was that we wanted to define it in *one* single place and have a consistent document everywhere.

Of course, there might be other recommendations (such as ssh config snippets) which do not need this cipherstringB macro. But that's ok. But basically everything else does.

So... thank you very much for your offering of time to clean this up.
Much appreciated! It's good to see activity again :)



On Oct 10, 2014, at 2:08 PM, Tobias Pape <Das.Linux at gmx.de> wrote:

> Hi
> 
> On 10.10.2014, at 10:16, Bertuch, Oliver <o.bertuch at fz-juelich.de> wrote:
> 
>> Dear list,
>> 
>> let me open this thread to continue the discussion rising in GitHub PR 74 [1].
>> 
>> Tobias wrote:
>>> [...]
>>> 
>>> The TeX files take what is there, it is about the linked (example-)config files.
>>> Yes, it is theoretically possible to use macros and the like for included stuff (We had that), but it is
>>> painful and produces sub-standard output.
>>> 
>> Agreed.
>>> IMHO a working way would be:
>>> 
>>> 	• Have all config files (from src/configuration/) moved to a template (eg, configuration.template/)
>>> 	• Replace hard-coded cipherstring with @@CIPHERSTRINGB@@
>> Agreed. What about the special cipherstrings for the Webserver configs? These are quite different from CIPHERSTRINGA and CIPHERSTRINGB. To be consistent within the guide, these "exceptions" should be replaced. But then what about OpenSSH configs? Those are in no way going to fit to a normal cipher string.
>> 
>> Maybe we should define some well described exeptions (why, what, differences to A/B, ...), which have their own macro?
> 
> Sounds reasonable to me.
> 
>>> And then to produce something usable:
>>> 
>>> 	• Run a sed cmd on every file file in configuration.template and put them into configuration (or src/configuration for that matter
>>> 	• “Deliver” only files from the build configurations (not the templates)
>>> 		• via the repository (i.e., update the configuration folder on every change to the cipherstring)
>>> 		• via the bettercrypto site
>>> 		• in the generated TeX output
>>> 		• (in hypothetical ebooks and whatnot…)
>> Sed is a good option, available on most Linux systems. 
>> 
>> Maybe do something like this:
>> - create new branch "delivery"
ACK
>> - in branch master, provide the templates
ACK
>> - in branch delivery, provide the "compiled" stuff
ACK
>> - changes in master get merged into delivery, preferably via CI (Travis?)
I don't know travis but a simple cp template/* delivery/ ; for f in delivery/* ; do sed -i $f ....; done
should do as well (?)

>> - delivery is the base for every further action like PDF rendering, HTML, ebooks, ... (maybe generated via CI?)
>> 
ACK

>> One pitfall I see arising anyway: if one changes this to use templates, what about the \configfile macro in the TeX sources? There are plenty of this using something like \configfile{<line1>-<line2>}{<path>}, but in the templates the line numbers will be different from the ones in the "compiled" sources.
> 
> I don't think so. the Cipherstring is always a one-liner.
> 
> 
>>> [...]
>>> (I wont have time to do that before November, tho…)
>>> 
>> If you are interested, I am willing to contribute to this. My employer is somewhat interested in this... ;)
> 
> It is mostly copy/paste and writing this sed-thing and integrating this
> into the Makefile.
> 

Thanks!
Aaron.

-------------- 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/20141011/1ba7432b/attachment.sig>