4 ms·

An easy cut-off point to avoid axing Free Software is to limit to commercial activity: you want to sell software for money? You are liable. Your software depend

An easy cut-off point to avoid axing Free Software is to limit to commercial activity: you want to sell software for money? You are liable. Your software depends on some library? Then you’re liable for this library too… unless you can have someone else accept liability, and trace that in the SBOM. Concrete example: I wrote a cryptographic library, which I give away for free. No guarantee, no liability, if I make a mistake the only thing you can take away is my reputation. But what if you want to use my library, and don’t want to be liable for it? There are two alternatives: you can approach me and pay me for me to accept liability… or you can approach a reputable audit company, and have them accept liability for a given version. Legislate like that, and I’ll still be able to contribute potentially critical code for free.

c0pium 3y ago
Contributing critical code for free is a non-goal, and having critical software that the creator has no liability for is an antipattern. You’re crowding out safer software with a free option and everyone is worse off for it.
- loup-vaillant 3y ago
  Yeah, yeah I have heard this time and again. Do you know what critical code you’re talking about? I’m not hard to search: https://duckduckgo.com/?q=loup-vaillant+cryptographic+library https://duckduckgo.com/?q=loup-vaillant+cryptographic+librar... And yes it is a risk. And yes I had one critical bug in 6 years, the horror. I did it anyway because it was pushing the Pareto envelope (speed/size mostly). And of course I knew what I was getting into, which is why it is not a weekend project, but a professional grade library. More explanations on my choices here: https://monocypher.org/why/ https://monocypher.org/why/ And by the way, Monocypher is currently being used to operate the TKey from Tillitis. https://tillitis.se/products/tkey/ https://tillitis.se/products/tkey/ Good luck porting libsodium there. --- You do have a point however: actively distributed critical software with no one being liable is an anti-pattern. Though strictly speaking, my code is only critical when it starts being used, so… we’re going back to the place of amateur work: if you want to use my code, you can pay me to get a license that does not waive my liability, or you can pay someone else to audit my library, or you can be liable yourself. And if I sell my code, I should indeed be automatically liable. The point with my example is that with proper legislation, even cryptographic libraries can continue being open source.
  - c0pium 3y ago
    I don’t see how what code it is matters, the principle doesn’t change based on the people involved. The people who wrote OpenSSL thought they knew what they were doing. As did the people who approved Dual_EC_DRBG. “Professional grade library” is an interesting choice of words in a thread about how we need to have liability for software, especially for software that is today in use exclusively licensed under no-liability licensing. If anything, all of the words on your site make it worse. A reasonable person, upon reading those fancy words, would be lead to the conclusion that this is Serious Software and thus safe to use. Are you liable under the license they’re using? Their site has a lot of “trust me bro” security words on it, which is a great illustration of my point. You wrote it, you chose of your own free will to make it available, you’re responsible if it gets people hurt.
    - loup-vaillant 3y ago
      Understand here that a couple comments and a read of the website just aren’t enough to give you an informed opinion. The best I can do here is "trust me bro", and a bit of social validation: https://monocypher.org/quality-assurance/audit https://monocypher.org/quality-assurance/audit (Cure53 audit, no bug found), https://www.mail-archive.com/curves@moderncrypto.org/msg01021.html https://www.mail-archive.com/curves@moderncrypto.org/msg0102... (Curve448 inventor says "Monocypher is an impressive piece of work.") > The people who wrote OpenSSL thought they knew what they were doing. The people who wrote OpenSSL had a much harder job, and my epistemic position is a lot better: I have over 20 years worth of additional collective wisdom to draw from, the primitives I implement are much* easier to deal with, and the problem I set out to solve is at least one order of magnitude easier. > Are you liable under the license they’re using? I’m not. And to be honest I’m on the fence on whether I should be. Nobody paid me for this work after all. On the other hand, if a law made me liable I wouldn’t complain too much to be honest. If it’s regulation more than liability, I already followed most, if not all, the procedures outlined in the upcoming EU law on software resilience. I should have little problem going all the way to full compliance there (except perhaps if they ask for third party audits, I’m not paying 6.000€ per release). > you’re responsible if it gets people hurt. Believe me, I know. Thankfully so far nobody reported being hurt in any way — even from the sevcrit. And I continue making sure it stays that way. --- By the way, I’m planning to work on an FPGA RISC-V core soon. I’m pretty sure nobody will give me any flak for this. And yet when you look at it, this is even more critical than a cryptographic library.
- flir 3y ago
  I dealt with closed source enterprise web servers back in the 90s. I am pretty sure Apache and nginx are safer. Maybe there are examples where that's not true, but my gut feeling is that "all eyes are shallow". Or something.
  - c0pium 3y ago
    Httpd was an absolute disaster from a security standpoint in the 90s, as was everything. Modsecurity didn’t even come out until 2002. Comparing nginx (released in 2004) is apples and oranges to say the least. OpenSSL or log4j would like a word about how shallow bugs are in popular software.
    - flir 3y ago
      First para is fair, I think.

c0pium 3y ago

Contributing critical code for free is a non-goal, and having critical software that the creator has no liability for is an antipattern. You’re crowding out safer software with a free option and everyone is worse off for it.

loup-vaillant 3y ago
Yeah, yeah I have heard this time and again. Do you know what critical code you’re talking about? I’m not hard to search: https://duckduckgo.com/?q=loup-vaillant+cryptographic+library https://duckduckgo.com/?q=loup-vaillant+cryptographic+librar... And yes it is a risk. And yes I had one critical bug in 6 years, the horror. I did it anyway because it was pushing the Pareto envelope (speed/size mostly). And of course I knew what I was getting into, which is why it is not a weekend project, but a professional grade library. More explanations on my choices here: https://monocypher.org/why/ https://monocypher.org/why/ And by the way, Monocypher is currently being used to operate the TKey from Tillitis. https://tillitis.se/products/tkey/ https://tillitis.se/products/tkey/ Good luck porting libsodium there. --- You do have a point however: actively distributed critical software with no one being liable is an anti-pattern. Though strictly speaking, my code is only critical when it starts being used, so… we’re going back to the place of amateur work: if you want to use my code, you can pay me to get a license that does not waive my liability, or you can pay someone else to audit my library, or you can be liable yourself. And if I sell my code, I should indeed be automatically liable. The point with my example is that with proper legislation, even cryptographic libraries can continue being open source.
- c0pium 3y ago
  I don’t see how what code it is matters, the principle doesn’t change based on the people involved. The people who wrote OpenSSL thought they knew what they were doing. As did the people who approved Dual_EC_DRBG. “Professional grade library” is an interesting choice of words in a thread about how we need to have liability for software, especially for software that is today in use exclusively licensed under no-liability licensing. If anything, all of the words on your site make it worse. A reasonable person, upon reading those fancy words, would be lead to the conclusion that this is Serious Software and thus safe to use. Are you liable under the license they’re using? Their site has a lot of “trust me bro” security words on it, which is a great illustration of my point. You wrote it, you chose of your own free will to make it available, you’re responsible if it gets people hurt.
  - loup-vaillant 3y ago
    Understand here that a couple comments and a read of the website just aren’t enough to give you an informed opinion. The best I can do here is "trust me bro", and a bit of social validation: https://monocypher.org/quality-assurance/audit https://monocypher.org/quality-assurance/audit (Cure53 audit, no bug found), https://www.mail-archive.com/curves@moderncrypto.org/msg01021.html https://www.mail-archive.com/curves@moderncrypto.org/msg0102... (Curve448 inventor says "Monocypher is an impressive piece of work.") > The people who wrote OpenSSL thought they knew what they were doing. The people who wrote OpenSSL had a much harder job, and my epistemic position is a lot better: I have over 20 years worth of additional collective wisdom to draw from, the primitives I implement are much* easier to deal with, and the problem I set out to solve is at least one order of magnitude easier. > Are you liable under the license they’re using? I’m not. And to be honest I’m on the fence on whether I should be. Nobody paid me for this work after all. On the other hand, if a law made me liable I wouldn’t complain too much to be honest. If it’s regulation more than liability, I already followed most, if not all, the procedures outlined in the upcoming EU law on software resilience. I should have little problem going all the way to full compliance there (except perhaps if they ask for third party audits, I’m not paying 6.000€ per release). > you’re responsible if it gets people hurt. Believe me, I know. Thankfully so far nobody reported being hurt in any way — even from the sevcrit. And I continue making sure it stays that way. --- By the way, I’m planning to work on an FPGA RISC-V core soon. I’m pretty sure nobody will give me any flak for this. And yet when you look at it, this is even more critical than a cryptographic library.
flir 3y ago
I dealt with closed source enterprise web servers back in the 90s. I am pretty sure Apache and nginx are safer. Maybe there are examples where that's not true, but my gut feeling is that "all eyes are shallow". Or something.
- c0pium 3y ago
  Httpd was an absolute disaster from a security standpoint in the 90s, as was everything. Modsecurity didn’t even come out until 2002. Comparing nginx (released in 2004) is apples and oranges to say the least. OpenSSL or log4j would like a word about how shallow bugs are in popular software.
  - flir 3y ago
    First para is fair, I think.