|Summary:||ftp/proftpd: dhparams file is stale|
|Product:||Ports & Packages||Reporter:||florian.heigl|
|Component:||Individual Port(s)||Assignee:||Martin Matuska <mm>|
|Severity:||Affects Some People||CC:||florian.heigl, w.schwarzenfeld|
Description florian.heigl 2016-04-21 11:46:10 UTC
Hi, this port brings along a dhparams file that was last re-generated in 2013; it should be re-generated and not include any <3072 params. per size it also only has a single param which, as far as I remember, isn't ideal either. It's also doubtful why it has it's own in general, /etc/ssh/moduli *might* be compatible (but probably not accessible if running non-root) At least maybe using the same source file for that could help.
Comment 1 florian.heigl 2016-04-21 11:48:50 UTC
Another thing that worries me here but totally doesn't relate to this port: Did noone ever audit the ports tree as a whole for high-entropy things like this after all the NSA shit came down? No idea who to ask about that, but I see a corpse right here and its rotten.
Comment 2 Walter Schwarzenfeld 2018-01-13 03:48:27 UTC
Comment 3 florian.heigl 2018-01-13 11:51:06 UTC
I didn't hear anything, and had long forgotten about the issue. If you know how to get a security person to look into it, please go ahead. Somehow it seems I just can't "find" the proper channel in cases like this. I just checked and I really did replace it everywhere in the env I helped run back then: (ansible snippet that should work everywhere follows) - name: do not use upstream dhparams file shell: rsync -ci /etc/ssh/moduli /usr/local/etc/proftpd/dhparams.pem register: rsync_result changed_when: 'rsync_result.stdout != ""' )