11 ms·

OpenSSL after Heartbleed

113 points by Halienja 10y ago

jvermillard 10y ago
I recently experienced a bug with OpenSSL 1.1 and the team was pretty reactive! I'm using OpenSSL 1.1 because it's the only DTLS implementation featuring all the extensions (OCSP stappling) and ciphersuites (AES-CCM-8) I need.
mSparks 10y ago
For me, Heartbleed was much much more than: ->At its core, Heartbleed was a simple bug, a missing buffer-length check It was a catastrophic failure of a critical internet component that highlighted the truth that these supposed crypto security experts didnt have a clue. We're talking about the kind of "simple bug" analogous to a television with bare wires as a power switch. Imho it will take a lot more than a couple of years and a team change to reinspire faith in that brand of security. If we should at all.
- DasIch 10y ago
  I think that's somewhat unfair. People make mistakes, that's unavoidable and shouldn't be seen as an issue. Instead of blaming people for making mistakes we should consider what we can learn. We need to identify which mistakes happened, why they happened and what measures we can take to make such mistakes impossible or unlikely in the future. It turns out that the industry is really bad that problem. Many libraries and critical parts of the infrastructure are developed using languages and tools that don't just allow mistakes to happen that can be prevented but make it easy to make such mistakes. Crypto is affected by this but there are many other areas which are affected by this problem to. There needs to be a move towards more constrained languages like Rust that limit the potential mistakes, better development processes that prevent bugs from passing through that can be caught by humans and tools for testing that make it possible to test for a wider range of problems and not just those developers anticipate to occur.
  - dijit 10y ago
    I see the same sentiment all the time here on HN. "Just reimplement it in rust" Well, why do you think openssl is so pervasive? It's everywhere and it's not due to marketing or ease of use or code quality. It's because nobody in their right mind wants to implement a TLS library. Openssl itself was only conceived because the original author was teaching himself C.
    - DasIch 10y ago
      I'm mentioning Rust to make clear the direction I'd like things to go and because there isn't really an alternative that allows for similar reusability and is practical for developing cryptographic libraries. That being said there are also implementations of TLS in other languages like Haskell or OCaml, that also wouldn't be vulnerable to these kinds of issues. I agree that this is a difficult problem but I don't think that's really the barrier here. AI is also difficult and there is no shortage of improvement in that area. The real problem isn't the difficulty of implementing a TLS library, the real problem is inertia and an unwillingness to change.
      - duneroadrunner 10y ago
        SaferCPlusPlus[1] is an easier option when starting from a C/C++ code base. It's also one of the faster options, but if people are willing to accept some performance cost, I think the easiest solution would probably be to "harden" the LLVM/gcc sanitizers so that they can be used in deployed builds, not just debug builds. The sanitizers don't catch everything, but pretty close it seems. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus https://github.com/duneroadrunner/SaferCPlusPlus
        nickpsecurity 10y ago
        I'll add that SAFEcode and Softbound+CETS automatically make C programs memory-safe against lots of problems. There was also the Clay language that could've been updated. C0 is a subset that was easier to verify used in Verisoft's microkernel and apps. Rod Chapman found an error in reference implementation recoding it in SPARK Ada. So that could be used. All kinds of things could solve the C-level problems or substitute with a C wrapper but nobody cares enough to do it.
- cheiVia0 10y ago
  The problem was bigger than that, basically no-one cares about their open source infrastructure and so it (including OpenSSL) is continually under-resourced.
- zeveb 10y ago
  It's yet another in a long line of bugs due to C. It is, of course, possible to have bugs in every language. Even in a theoretical bug-free language it'd be possible to flawlessly implement a buggy algorithm or standard. But some languages make some sorts of bug difficult, and others make them easy: C is in the latter group. I suspect that assembler for the primitives and a good, sane high-level language (Haskell? Caml? Lisp?) would yield far more secure software than C. There are issues with relocatable memory and zeroing of keys, but those are, I think, addressable at the implementation level.
  - acqq 10y ago
    I don't have an impression that any of the mentioned languages can provide reasonable alternative to the library written in C or the equivalently compatible language, and the only language that it appears to me to have a chance to have such an implementation could be Rust, but somehow even there it appears to be too hard to do so and/or too little commercial interest to make something "good enough" for the most of the potential users. The Rust community doesn't have to implement all the functionality of Open SSL, but if it would produce at least just a proof of concept (e.g. just a minimal set of algorithms) which would prove both the capability to achieve the same speed and the provably higher security, that would be, I think, a huge start. That would mean not wrapping the whole OpenSSL library in Rust calls but having some as minimal as possible, the tightest of the tightest loops implemented in ASM and everything else in clean and "secure" (not downgraded to the C freedom) Rust which would also pass the benchmarks and be capable to be called "on the high level" from the C code to which that library could be linked (probably the Rust code would not use GC or if it would it would have to be some so simple and minimal one that it would work by eventually calling the C malloc for bigger blocks and cause no different delays than the good written C). Not easy but I think theoretically possible for Rust. Once it would be achieved, implementing other algorithms would be possible to be done by different people and organizations. I guess in order to achieve these goals the language designers would have to directly decide to support them, but I'd be glad if the status is already different. But I really believe that would be a huge argument for Rust: being provably more secure than C and achieving ability to implement effective drop-in replacements for C security libraries. Is it too high a goal? I don't know how far we are from something like that, but maybe some Rust insider can estimate? What's still missing and how far we are from the point where what I described would be possible to implement?
TwoBit 10y ago
Whenever there's an article about OpenSSL, I get on my soapbox to talk about how shitty it is. The design is terrible, both internally and in the public API. Building it is a PITA. It is almost completely unaware of this thing called multithreading. It still is hard-coded to be able to read certificates only via disk files with fopen, despite having a screwy BIO system which is a half baked attempt at sometimes abstracting IO. If it was anything other than a security library, it would have died long ago.
- dom0 10y ago
  I contribute to some software that's relatively widely deployed and needs crypto primitives. Sadly on Linux there are few choices that support common algorithms and is usually available. The alternatives sometimes exhibit performance issues due to missing optimizations as well, or simply don't support the needed algorithms. On the other hand OpenSSL took it's sweet time to implement eg. 25519 based crypto or chacha20 which is also a pain - today Chacha20-Poly1305 is the only viable AEAD crypto system for embedded/low-computing-capability devices, including those with AES acceleration. Another thing I'd like to ramble about a bit is their API/release management. In 1.1 they made a bunch of structures opaque - which is good IMHO - but due to the very inconsistent APIs before they needed to add some utility APIs to handle opaque structs in some places; instead of backporting those to 1.0.x, so that you, as an application developer, don't need to add conditional compilation and shims to every application, they chose not to. Additionally shims posted in the wiki were (maybe still are) wrong. Forcing application developers to figure out API compatibility code for a crypto library is bad. That code will be tested very little or not at all, additionally it's hard to test. Cryptography on Linux (or - on most platforms) is still in a bad shape.
  - cristinamillion 10y ago
    > Cryptography on Linux (or - on most platforms) is still in a bad shape. libsodium addresses the non-TLS part of this pretty well, doesn't it? I know it doesn't have any native password-based KDF that won't DOS your device under anything but simple load, but otherwise it uses good algorithms. > today Chacha20-Poly1305 is the only viable AEAD crypto system for embedded/low-computing-capability devices, including those with AES acceleration. True, but there are some nice-looking AEAD candidates in the CAESAR competition, some of which out-perform AES-GCM and CHACHA20 by a good margin. We'd probably all be using OCB mode if Rogaway hadn't used such a bizarre initial license (which took a few iterations to get in a sane state and still require you to pay him something like $70,000 USD for use in commercial embedded systems).
__david__ 10y ago
Interesting, I had no idea the changes that were happening to OpenSSL. It's sad that it took Heartbleed to kick it in the butt, but it's heartening that they appear to be heading in a better direction now. I'm also curious how LibreSSL is doing—I haven't heard much about it lately. Did it fizzle, or is it still making good progress?
- Leynos 10y ago
  LibreSSL is part of the OpenBSD base system, and that is their primary target AIUI. They also maintain a portable version with support for a wider range of operating systems. There's a good summary of LibreSSL's track record over the past two years in comparison with OpenSSL on the LibreSSL Wikipedia page (https://en.wikipedia.org/wiki/LibreSSL#Security_and_vulnerabilities https://en.wikipedia.org/wiki/LibreSSL#Security_and_vulnerab...). There was also news a few days ago (https://news.ycombinator.com/item?id=12691733 https://news.ycombinator.com/item?id=12691733) that Alpine Linux is adopting LibreSSL Portable in place of OpenSSL.
zAy0LfpBZLC8mAC 10y ago
> Needless to say, OpenSSL is looking for contributors. Beyond contributing patches, interested developers can test the pre-releases, report bugs, and help to close bugs. The presenters concluded by saying that they would like users to get in touch, especially those who are distributing OpenSSL further downstream. ... and just a few days later they closed ~ 150 bugs, some with patches attached, "because they were too old": https://www.openssl.org/blog/blog/2016/10/12/f2f-rt-github/ https://www.openssl.org/blog/blog/2016/10/12/f2f-rt-github/ https://mta.openssl.org/pipermail/openssl-dev/2016-October/008638.html https://mta.openssl.org/pipermail/openssl-dev/2016-October/0...
- akira2501 10y ago
  That was something else that irked me in the article, where they decry the small $2,000 a year they receive in donations; but they don't address how much their commercial support contracts[1] bring in. OpenSSL seems to be both an open source project and a cottage industry all wrapped in one. [1] https://www.openssl.org/support/contracts.html https://www.openssl.org/support/contracts.html
  - vtlynch 10y ago
    The first date that Archive.org has that page is August 2015, after heartbleed. Do you know for sure that they offered this service before heartbleed?
    - LukeShu 10y ago
      Yes. https://web.archive.org/web/20120805001248/http://www.openssl.org/support/funding/contract.html https://web.archive.org/web/20120805001248/http://www.openss... August 2015 is just when they did a website redesign, which caused some URLs to change.
      - vtlynch 10y ago
        Good find. This is an excellent question. Knowing how much OpenSSL made through this is certainly important.
iUsedToCode 10y ago
How come the biggest names in IT don't work towards creating a modern, better security library? It's pennies for them, they wouldn't even see it on the balance. Having security issues slows down business significantly. Non-geeks keep hearing about major bugs in basic security and it surely has a negative effect on the spread of internet and services based on it.
- yalooze 10y ago
  There is LibreSSL[0] which is a fork of OpenSSL done primarily by the OpenBSD team (it was created as a direct response to Heartbleed). BoringSSL[1] is Google's attempt. [0] https://www.libressl.org/ https://www.libressl.org/ [1] https://boringssl.googlesource.com/boringssl/ https://boringssl.googlesource.com/boringssl/
  - throwaway7767 10y ago
    LibreSSL is OpenSSL with some of the ugly bits stripped out. It's still aiming for compatibility, and so it retains many of the warts and will continue to do so. It's not a modern library though it may be a bit better than OpenSSL. BoringSSL is similar, except there you additionally have the problem that google strongly discourages its use by third parties, as they consider it an internal library and semantics can change. A better example of a modern library would be NaCL or libsodium.
    - stephen_g 10y ago
      That's not accurate - the LibreSSL developers have overhauled the internals fairly substantially in a lot of ways, and they are also making a sensible API on top of it (libtls).
  - gbrown_ 10y ago
    > it was created as a direct response to Heartbleed The reason for the fork was not Heartbleed itself but the crazy memory allocation done behind the scenes. https://youtu.be/GnBbhXBDmwU?t=308 https://youtu.be/GnBbhXBDmwU?t=308
  - 10y ago
cm3 10y ago
The original NaCl had assembly implementations, I believe generated with a Perl script (not unlike OpenSSL's asm generator), and looking around libsodium I cannot see assembly implementations of the loops. Does anyone know why that is? I believe the Linux kernel implementation of ChaCha20 carries asm versions.
zeveb 10y ago
> The code was hard to maintain and hard to contribute to, especially for developers in the US due to crypto export issues. That's not really true: per https://www.bis.doc.gov/index.php/policy-guidance/encryption/registration#One https://www.bis.doc.gov/index.php/policy-guidance/encryption..., publicly available software (which includes free software) just requires a notification under exception TSU. All you have to do, per https://www.law.cornell.edu/cfr/text/15/740.13 https://www.law.cornell.edu/cfr/text/15/740.13, is send an email to crypt@bis.doc.gov and to enc@nsa.gov with the location of the source code. As long as you don't change the location, you never have to worry about it again. The regulation even notes that simply providing source code on a public website does not constitute export to a prohibited country. It's really not a big deal. (Note: I am not a lawyer; this does not constitute legal advice)
zengid 10y ago
>A recently added tool will modify the code to invert the sense of the conditions in if statements to see whether the test suite catches the resulting bug; if it doesn't, there is a coverage gap in the test suite. Does anyone have any info on this tool? I'm intrigued.

113 points by Halienja 10y ago

I recently experienced a bug with OpenSSL 1.1 and the team was pretty reactive! I'm using OpenSSL 1.1 because it's the only DTLS implementation featuring all the extensions (OCSP stappling) and ciphersuites (AES-CCM-8) I need.

mSparks 10y ago

For me, Heartbleed was much much more than: ->At its core, Heartbleed was a simple bug, a missing buffer-length check It was a catastrophic failure of a critical internet component that highlighted the truth that these supposed crypto security experts didnt have a clue. We're talking about the kind of "simple bug" analogous to a television with bare wires as a power switch. Imho it will take a lot more than a couple of years and a team change to reinspire faith in that brand of security. If we should at all.

DasIch 10y ago
I think that's somewhat unfair. People make mistakes, that's unavoidable and shouldn't be seen as an issue. Instead of blaming people for making mistakes we should consider what we can learn. We need to identify which mistakes happened, why they happened and what measures we can take to make such mistakes impossible or unlikely in the future. It turns out that the industry is really bad that problem. Many libraries and critical parts of the infrastructure are developed using languages and tools that don't just allow mistakes to happen that can be prevented but make it easy to make such mistakes. Crypto is affected by this but there are many other areas which are affected by this problem to. There needs to be a move towards more constrained languages like Rust that limit the potential mistakes, better development processes that prevent bugs from passing through that can be caught by humans and tools for testing that make it possible to test for a wider range of problems and not just those developers anticipate to occur.
- dijit 10y ago
  I see the same sentiment all the time here on HN. "Just reimplement it in rust" Well, why do you think openssl is so pervasive? It's everywhere and it's not due to marketing or ease of use or code quality. It's because nobody in their right mind wants to implement a TLS library. Openssl itself was only conceived because the original author was teaching himself C.
  - DasIch 10y ago
    I'm mentioning Rust to make clear the direction I'd like things to go and because there isn't really an alternative that allows for similar reusability and is practical for developing cryptographic libraries. That being said there are also implementations of TLS in other languages like Haskell or OCaml, that also wouldn't be vulnerable to these kinds of issues. I agree that this is a difficult problem but I don't think that's really the barrier here. AI is also difficult and there is no shortage of improvement in that area. The real problem isn't the difficulty of implementing a TLS library, the real problem is inertia and an unwillingness to change.
    - duneroadrunner 10y ago
      SaferCPlusPlus[1] is an easier option when starting from a C/C++ code base. It's also one of the faster options, but if people are willing to accept some performance cost, I think the easiest solution would probably be to "harden" the LLVM/gcc sanitizers so that they can be used in deployed builds, not just debug builds. The sanitizers don't catch everything, but pretty close it seems. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus https://github.com/duneroadrunner/SaferCPlusPlus
      - nickpsecurity 10y ago
        I'll add that SAFEcode and Softbound+CETS automatically make C programs memory-safe against lots of problems. There was also the Clay language that could've been updated. C0 is a subset that was easier to verify used in Verisoft's microkernel and apps. Rod Chapman found an error in reference implementation recoding it in SPARK Ada. So that could be used. All kinds of things could solve the C-level problems or substitute with a C wrapper but nobody cares enough to do it.
cheiVia0 10y ago
The problem was bigger than that, basically no-one cares about their open source infrastructure and so it (including OpenSSL) is continually under-resourced.
zeveb 10y ago
It's yet another in a long line of bugs due to C. It is, of course, possible to have bugs in every language. Even in a theoretical bug-free language it'd be possible to flawlessly implement a buggy algorithm or standard. But some languages make some sorts of bug difficult, and others make them easy: C is in the latter group. I suspect that assembler for the primitives and a good, sane high-level language (Haskell? Caml? Lisp?) would yield far more secure software than C. There are issues with relocatable memory and zeroing of keys, but those are, I think, addressable at the implementation level.
- acqq 10y ago
  I don't have an impression that any of the mentioned languages can provide reasonable alternative to the library written in C or the equivalently compatible language, and the only language that it appears to me to have a chance to have such an implementation could be Rust, but somehow even there it appears to be too hard to do so and/or too little commercial interest to make something "good enough" for the most of the potential users. The Rust community doesn't have to implement all the functionality of Open SSL, but if it would produce at least just a proof of concept (e.g. just a minimal set of algorithms) which would prove both the capability to achieve the same speed and the provably higher security, that would be, I think, a huge start. That would mean not wrapping the whole OpenSSL library in Rust calls but having some as minimal as possible, the tightest of the tightest loops implemented in ASM and everything else in clean and "secure" (not downgraded to the C freedom) Rust which would also pass the benchmarks and be capable to be called "on the high level" from the C code to which that library could be linked (probably the Rust code would not use GC or if it would it would have to be some so simple and minimal one that it would work by eventually calling the C malloc for bigger blocks and cause no different delays than the good written C). Not easy but I think theoretically possible for Rust. Once it would be achieved, implementing other algorithms would be possible to be done by different people and organizations. I guess in order to achieve these goals the language designers would have to directly decide to support them, but I'd be glad if the status is already different. But I really believe that would be a huge argument for Rust: being provably more secure than C and achieving ability to implement effective drop-in replacements for C security libraries. Is it too high a goal? I don't know how far we are from something like that, but maybe some Rust insider can estimate? What's still missing and how far we are from the point where what I described would be possible to implement?

TwoBit 10y ago

Whenever there's an article about OpenSSL, I get on my soapbox to talk about how shitty it is. The design is terrible, both internally and in the public API. Building it is a PITA. It is almost completely unaware of this thing called multithreading. It still is hard-coded to be able to read certificates only via disk files with fopen, despite having a screwy BIO system which is a half baked attempt at sometimes abstracting IO. If it was anything other than a security library, it would have died long ago.

dom0 10y ago
I contribute to some software that's relatively widely deployed and needs crypto primitives. Sadly on Linux there are few choices that support common algorithms and is usually available. The alternatives sometimes exhibit performance issues due to missing optimizations as well, or simply don't support the needed algorithms. On the other hand OpenSSL took it's sweet time to implement eg. 25519 based crypto or chacha20 which is also a pain - today Chacha20-Poly1305 is the only viable AEAD crypto system for embedded/low-computing-capability devices, including those with AES acceleration. Another thing I'd like to ramble about a bit is their API/release management. In 1.1 they made a bunch of structures opaque - which is good IMHO - but due to the very inconsistent APIs before they needed to add some utility APIs to handle opaque structs in some places; instead of backporting those to 1.0.x, so that you, as an application developer, don't need to add conditional compilation and shims to every application, they chose not to. Additionally shims posted in the wiki were (maybe still are) wrong. Forcing application developers to figure out API compatibility code for a crypto library is bad. That code will be tested very little or not at all, additionally it's hard to test. Cryptography on Linux (or - on most platforms) is still in a bad shape.
- cristinamillion 10y ago
  > Cryptography on Linux (or - on most platforms) is still in a bad shape. libsodium addresses the non-TLS part of this pretty well, doesn't it? I know it doesn't have any native password-based KDF that won't DOS your device under anything but simple load, but otherwise it uses good algorithms. > today Chacha20-Poly1305 is the only viable AEAD crypto system for embedded/low-computing-capability devices, including those with AES acceleration. True, but there are some nice-looking AEAD candidates in the CAESAR competition, some of which out-perform AES-GCM and CHACHA20 by a good margin. We'd probably all be using OCB mode if Rogaway hadn't used such a bizarre initial license (which took a few iterations to get in a sane state and still require you to pay him something like $70,000 USD for use in commercial embedded systems).

__david__ 10y ago

Interesting, I had no idea the changes that were happening to OpenSSL. It's sad that it took Heartbleed to kick it in the butt, but it's heartening that they appear to be heading in a better direction now. I'm also curious how LibreSSL is doing—I haven't heard much about it lately. Did it fizzle, or is it still making good progress?

Leynos 10y ago
LibreSSL is part of the OpenBSD base system, and that is their primary target AIUI. They also maintain a portable version with support for a wider range of operating systems. There's a good summary of LibreSSL's track record over the past two years in comparison with OpenSSL on the LibreSSL Wikipedia page (https://en.wikipedia.org/wiki/LibreSSL#Security_and_vulnerabilities https://en.wikipedia.org/wiki/LibreSSL#Security_and_vulnerab...). There was also news a few days ago (https://news.ycombinator.com/item?id=12691733 https://news.ycombinator.com/item?id=12691733) that Alpine Linux is adopting LibreSSL Portable in place of OpenSSL.

zAy0LfpBZLC8mAC 10y ago

> Needless to say, OpenSSL is looking for contributors. Beyond contributing patches, interested developers can test the pre-releases, report bugs, and help to close bugs. The presenters concluded by saying that they would like users to get in touch, especially those who are distributing OpenSSL further downstream. ... and just a few days later they closed ~ 150 bugs, some with patches attached, "because they were too old": https://www.openssl.org/blog/blog/2016/10/12/f2f-rt-github/ https://www.openssl.org/blog/blog/2016/10/12/f2f-rt-github/ https://mta.openssl.org/pipermail/openssl-dev/2016-October/008638.html https://mta.openssl.org/pipermail/openssl-dev/2016-October/0...

akira2501 10y ago
That was something else that irked me in the article, where they decry the small $2,000 a year they receive in donations; but they don't address how much their commercial support contracts[1] bring in. OpenSSL seems to be both an open source project and a cottage industry all wrapped in one. [1] https://www.openssl.org/support/contracts.html https://www.openssl.org/support/contracts.html
- vtlynch 10y ago
  The first date that Archive.org has that page is August 2015, after heartbleed. Do you know for sure that they offered this service before heartbleed?
  - LukeShu 10y ago
    Yes. https://web.archive.org/web/20120805001248/http://www.openssl.org/support/funding/contract.html https://web.archive.org/web/20120805001248/http://www.openss... August 2015 is just when they did a website redesign, which caused some URLs to change.
    - vtlynch 10y ago
      Good find. This is an excellent question. Knowing how much OpenSSL made through this is certainly important.

iUsedToCode 10y ago

How come the biggest names in IT don't work towards creating a modern, better security library? It's pennies for them, they wouldn't even see it on the balance. Having security issues slows down business significantly. Non-geeks keep hearing about major bugs in basic security and it surely has a negative effect on the spread of internet and services based on it.

yalooze 10y ago
There is LibreSSL[0] which is a fork of OpenSSL done primarily by the OpenBSD team (it was created as a direct response to Heartbleed). BoringSSL[1] is Google's attempt. [0] https://www.libressl.org/ https://www.libressl.org/ [1] https://boringssl.googlesource.com/boringssl/ https://boringssl.googlesource.com/boringssl/
- throwaway7767 10y ago
  LibreSSL is OpenSSL with some of the ugly bits stripped out. It's still aiming for compatibility, and so it retains many of the warts and will continue to do so. It's not a modern library though it may be a bit better than OpenSSL. BoringSSL is similar, except there you additionally have the problem that google strongly discourages its use by third parties, as they consider it an internal library and semantics can change. A better example of a modern library would be NaCL or libsodium.
  - stephen_g 10y ago
    That's not accurate - the LibreSSL developers have overhauled the internals fairly substantially in a lot of ways, and they are also making a sensible API on top of it (libtls).
- gbrown_ 10y ago
  > it was created as a direct response to Heartbleed The reason for the fork was not Heartbleed itself but the crazy memory allocation done behind the scenes. https://youtu.be/GnBbhXBDmwU?t=308 https://youtu.be/GnBbhXBDmwU?t=308
- 10y ago

cm3 10y ago

The original NaCl had assembly implementations, I believe generated with a Perl script (not unlike OpenSSL's asm generator), and looking around libsodium I cannot see assembly implementations of the loops. Does anyone know why that is? I believe the Linux kernel implementation of ChaCha20 carries asm versions.

zeveb 10y ago

> The code was hard to maintain and hard to contribute to, especially for developers in the US due to crypto export issues. That's not really true: per https://www.bis.doc.gov/index.php/policy-guidance/encryption/registration#One https://www.bis.doc.gov/index.php/policy-guidance/encryption..., publicly available software (which includes free software) just requires a notification under exception TSU. All you have to do, per https://www.law.cornell.edu/cfr/text/15/740.13 https://www.law.cornell.edu/cfr/text/15/740.13, is send an email to crypt@bis.doc.gov and to enc@nsa.gov with the location of the source code. As long as you don't change the location, you never have to worry about it again. The regulation even notes that simply providing source code on a public website does not constitute export to a prohibited country. It's really not a big deal. (Note: I am not a lawyer; this does not constitute legal advice)

zengid 10y ago

>A recently added tool will modify the code to invert the sense of the conditions in if statements to see whether the test suite catches the resulting bug; if it doesn't, there is a coverage gap in the test suite. Does anyone have any info on this tool? I'm intrigued.