I think the tide of blaming people running CURRENT and attempting to dismiss the issue instead of addressing the extremely serious vulnerability is troubling, since even in the limited Venn diagram of people I know that run FreeBSD, one of them matches this template:
1. STABLE prod fleet
2. CURRENT dev workstation
3. TLS certificate private keys in prod generated on CURRENT workstation to be signed by authority
4. Potentially vulnerable TLS keys existing in STABLE fleet
You folks can twist this to try to deflect severity by pointing to CURRENT, but in the real world, it existing at all for four months is extremely serious and must be taken seriously. My production TLS keys were created on my OS X laptop, because I don't often have to think about a compromised random number generator and this is a tradeoff I make in my own life.
I guess if I truly cared about my TLS keys, I should have made them on a copy of airgapped Warty Warthog and run them through a shitload of random analysis tools before shipping them off to be signed. My bad.
You might want to ask them again if 2 is true. In reality, I highly doubt they really use what you described in point 2. (or it's a miscommunication).
Unless they recompile world all the time (a nontrivial amount of work and a waste of time if you are not actively developing the OS itself) - CURRENT is actually much much slower because of debugging flags that are enabled by default. Some of these flags make the kernel panic upon certain types of errors and drop into kernel debugging mode allowing the examination of kernel dumps. I can't fathom why anyone would generate real security certificates in this kind of environment.
You can recompile with the WITNESS (kernel lock counting & validation - incurs performance loss but useful for counting kernel data structures) and INVARIANTS (run-time assertion checks and tests for kernel data structures) options off, but then you would have to spend time recompiling the kernel instead of working on your software.
Note that CURRENT is packaged as snapshot binaries without binary upgrade capability - which means that once you install "one day's" -CURRENT the only 2 ways to upgrade are a) download the new iso and reinstall the entire OS or b) check out the freebsd source code via svn and recompile the system (often world changes as well so you need to do both kernel + userland).
If 2. is actually true, then the person you know who is doing that, unless they are being paid to work on freebsd features or perhaps validating and porting freebsd to a different hardware platform like ARM or PS4 or an embedded device like a medical imaging device or a router (ie Junos), they are wasting a lot of their employer's time and foot-gunning themselves massively in security.
If you show them this post, ask them what they are doing with -CURRENT?
I am open to learning new things so I'd really like to know!
I spent way too much typing this reply. I should just join the freebsd development team and learn the answer to my own question.
Thinking about this again - yah - the poster might be referring to some kind of workflow like this:
production machines are platforms that run -STABLE
there is some kind of device, embedded or otherwise, that they keep locked up somewhere in a lab. It could be the new xxyz multicore switching fabric [imaginary name] that is running a new version of BSD-OS variant that's undergoing verification testing - they run hardware development and need -CURRENT's capabilities for debugging the system itself. It generates some keys that will be distributed into the pool of machines running -STABLE so that in the future, when this new variant comes into the market, there will be "pre-seeded" keys for compatability (ie. older versions of systems will be able to interact via signed certs with the new system)
Since FreeBSD is BSD licensed, there can be any number of things people are doing with it without anyone else knowing - so maybe to give the benefit of the doubt, I can envision a workflow that needs -CURRENT as a workstation / dev platform.
I think one weakness to my thinking is that VARIANTS/WITNESS/kdb/ddb can be enabled on -RELEASE and -STABLE distributions as well! Why not just do everything on -STABLE even if you need kernel debugging?
If they need -CURRENT for new hardware support, it shouldn't be too hard to figure out from the svn log and the rolling release notes. It's kinda fun trying to reverse engineer the job of the thread parent's acquaintance!
Or a tested, non-alpha, security team verified edition of FreeBSD?
I mean come on, We are not saying that you should only generate keys from cosmic rays and personal messages from $DEITY. Only that you do it on a production ready OS, is that really too much to expect?
On a side-note. Unless your devs are involved in the development of FreeBSD, why are they on -CURRENT?
Maybe I'm crazy or have spent too much time in banking instead of in hip startups or something, but I'm struggling to understand why you'd want to do private key generation on a workstation, especially a workstation running the unstable version of an OS (which might break at a moment's notice), instead of a stable production environment, ideally a fairly isolated one dedicated to the task.
I am pretty sure they are taking it seriously. If you did #3, then that is on you. It's a bloody bleeding edge version where nothing, NOTHING is guaranteed. If you generated your keys on a bleeding edge version and then moved them to STABLE, lordy you should be fired.
1. STABLE prod fleet
2. CURRENT dev workstation
3. TLS certificate private keys in prod generated on CURRENT workstation to be signed by authority
4. Potentially vulnerable TLS keys existing in STABLE fleet
You folks can twist this to try to deflect severity by pointing to CURRENT, but in the real world, it existing at all for four months is extremely serious and must be taken seriously. My production TLS keys were created on my OS X laptop, because I don't often have to think about a compromised random number generator and this is a tradeoff I make in my own life.
I guess if I truly cared about my TLS keys, I should have made them on a copy of airgapped Warty Warthog and run them through a shitload of random analysis tools before shipping them off to be signed. My bad.