3 ms·

Reading the comments here is somewhat frustrating. Even the most recent ones seem to miss the significance of the RNG bug being in the -CURRENT branch only. Th

Reading the comments here is somewhat frustrating. Even the most recent ones seem to miss the significance of the RNG bug being in the -CURRENT branch only. They found a bug, and it will be fixed. The fact that this bug was found in -CURRENT is a good a thing. This is a pre-alpha, not for production release. The development model is working as intended, no?

peri 12y ago
In my mind, no, it is not. But it's been a long time since I've contributed code to a *BSD.
- jontro 12y ago
  Can you describe in what way it's not working as intended?
  - peri 12y ago
    No, I couldn't do so two days ago, unfortunately. Sorry for any confusion.
jsmthrowaway 12y ago
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.
- sigzero 12y ago
  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.
- rurounijones 12y ago
  > I guess if I truly cared about my TLS keys 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?
- rodgerd 12y ago
  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.
- barkingcat 12y ago
  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. https://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-options.html https://www.freebsd.org/doc/en/books/developers-handbook/ker... 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!
emaste 12y ago
It is very good that the bug was found and fixed in -CURRENT, but it's also important not to be dismissive of the issue. It is unfortunate that some recent posters are clearly confusing -CURRENT with the stable branch from which releases are cut. However, this is a very serious flaw that existed in the tree for some time, and is indeed a big concern in the FreeBSD developer community.

peri 12y ago

In my mind, no, it is not. But it's been a long time since I've contributed code to a *BSD.

jontro 12y ago
Can you describe in what way it's not working as intended?
- peri 12y ago
  No, I couldn't do so two days ago, unfortunately. Sorry for any confusion.

jsmthrowaway 12y ago

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.

sigzero 12y ago
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.
rurounijones 12y ago
> I guess if I truly cared about my TLS keys 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?
rodgerd 12y ago
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.
barkingcat 12y ago
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. https://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-options.html https://www.freebsd.org/doc/en/books/developers-handbook/ker... 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!

emaste 12y ago

It is very good that the bug was found and fixed in -CURRENT, but it's also important not to be dismissive of the issue. It is unfortunate that some recent posters are clearly confusing -CURRENT with the stable branch from which releases are cut. However, this is a very serious flaw that existed in the tree for some time, and is indeed a big concern in the FreeBSD developer community.