5 ms·

You'd be supried how few people actually work on issues such as security in FreeBSD. Unfortunately, instead of using existing solutions to reduce their workload

• tptacek 10y ago
  Vulnerabilities don't bother me! All code has vulnerabilities. Meanwhile, the opportunity to use code built around a different (BSD-like) mindset is why you'd use FreeBSD instead of Linux in the first place. What freaks me out is simple problems of principle, like, "we won't disclose this vulnerability because we don't have a patch, even though we know there's an exploit available". Even if the exploit wasn't public, as long as you know it's out there, people need to know about it!
  • valarauca1 10y ago
    we won't disclose this vulnerability because we don't have a patch, even though we know there's an exploit available. This is some 1984 shit. It's a horrible policy. While yes it'll make it easier for bad actors to write exploits, it'll also allow for sys-admins to possibly mitigate those exploits, or add extra logging to make it easier to catch exploits. Not admitting your software has flaws until you fix them is beyond irresponsible.
  • loeg 10y ago
    Did you miss the directly following sentence? > We are reviewing this policy for cases where a proof-of-concept or working exploit is already public. The existing policy is flawed and they intend to fix it. It just hadn't been a problem before now.
    • tptacek 10y ago
      No, it was that sentence that moved me to comment! They're "reviewing this policy"? They were bound by the policy in this case? That's crazy. There's an exploit. They didn't write it. Nobody should have to wonder if they're going to disclose. Ultimately I just care about this as an object lesson for how to handle security incidents.
• cperciva 10y ago
  a home-made public key signature format instead of PGP How is 'openssl rsautl -sign' a "home-made" signature format? As for using GPG... given its security track record, that's one of the last things I'd want to consider using for verifying signatures on binary updates. or not using signatures at all for package files The pkg repository is signed.
  • ivoras 10y ago
    >> a home-made public key signature format instead of PGP > How is 'openssl rsautl -sign' a "home-made" signature format? It's RAW RSA DATA. You could argue it's more pure that way but if that were the case, noone would ask for more metadata-rich signatures. > As for using GPG... given its security track record, that's one of the last things I'd want to consider using for verifying signatures on binary updates. If you don't see the NIH-ism in that sentence, then I'm sorry, neither I nor nobody else can help you. > The pkg repository is signed. Can individual package files be verified off-line?
    • tedunangst 10y ago
      Is it not possible for cperciva's assessment of GPG to be accurate regardless of where it was invented?
    • cperciva 10y ago
      Whether code is crap is a completely separate question from where it was invented. Putting signatures onto the individual package files could expose users to mismatch attacks, and would also make it harder to defend against build-trojan theft of signing keys.
    • tptacek 10y ago
      I think Colin has the better argument here. You were hyperbolic when you called rsautl a "home-made format".
    • feld 10y ago
      Packages are not meant to be distributed ad-hoc. You're meant to host a repo and sign it.
• doozy 10y ago
  > Like writing freebsd-update in POSIX shell How is this a bad thing? It is part of the base system, so it's either /bin/sh or C.
• feld 10y ago
  The packages don't need signing! The repo database is signed and the package checksums are inside. If the checksum doesn't match, the package is refused to be installed. This is vastly simpler than signing every package.