4 ms·

To be blunt: if your library requires me to handle it differently than all the other software that exists, it's a bad library. If you break compatibility every

by guappa 2y ago

To be blunt: if your library requires me to handle it differently than all the other software that exists, it's a bad library. If you break compatibility every week you should not be writing a library at all. > This reminds me of the time Debian developers "knew better" with the openssh key handling... How much % of the CVEs that exists are from debian patches and how much is upstream developers? Can you confidently claim that upstream developers are better at security than debian developers? Or are you just picking a single example and ignoring all the rest of the data that you don't like? I have 3794 packages currently installed on my machines. If all of them required special handling like your snowflake library I'd just not be using a computer at all, because I certainly don't have the capacity to deal with 3794 special snowflakes.

ycombinatrix 2y ago
>Can you confidently claim that upstream developers are better at security than debian developers? With respect to the upstream application? Yes, obviously.
lmm 2y ago
> I certainly don't have the capacity to deal with 3794 special snowflakes. It's hardly unique. Every major language other than C/C++ (and Python, but Python is just a mess in general) works like Rust here. If anything I'd say it's the C people who are the snowflakes. > Can you confidently claim that upstream developers are better at security than debian developers? I can confidently claim that upstream has better policies. Debian routinely patches security-critical software without dedicated security review; this predictably lead to disaster in the past and will lead to disaster again. Also the Debian SSL key bug was not just one more CVE on a par with any other. It was probably the worst security bug ever seen in general-purpose software.
- guappa 2y ago
  > I can confidently claim that upstream has better policies. Debian has thousands of different upstream, you don't even know who they are, how can you claim to know their policies and to have evaluated all of them? Also, all the 1 person projects do not get fixes in a timely manner. As you would understand if there was any amount of reasoning behind your arguments. Are you done making stuff up or must you continue? > Also the Debian SSL key bug 1. Shit happens 2. If you want random data you read from /dev/random, an uninitialised buffer is NOT random. 3. If your example dates to over a decade ago, I'd say the track record is excellent.
  - lmm 2y ago
    > Debian has thousands of different upstream, you don't even know who they are, how can you claim to know their policies and to have evaluated all of them? Thousands of upstreams yes, thousands for security-critical software no. > 2. If you want random data you read from /dev/random, an uninitialised buffer is NOT random. That's not what was happening. Now who's making stuff up? > 3. If your example dates to over a decade ago, I'd say the track record is excellent. The worst bug in regular software had to happen at some point in time, it happens to have happened over a decade at all. It's not like Debian's record has been spotless since then.
    - guappa 2y ago
      > Thousands of upstreams yes, thousands for security-critical software no. Everything is security critical. > That's not what was happening. Now who's making stuff up? You, who didn't read the mailing list exchange > The worst bug in regular software had to happen at some point in time ??? How did you classify it? Were there any other contenders? Can you share which contenders were there?
- andrewshadura 2y ago
  > Debian routinely patches security-critical software without dedicated security review This is untrue. Provide some evidence or withdraw your false claim. Thanks.
  - ycombinatrix 2y ago
    They patched openssh without dedicated security review...which directly allowed the xz backdoor debacle. Checks out to me.
    - guappa 2y ago
      If you expect a bsd software to run unpatched on linux… I don't know what to say to you… except to tell you to try and do it yourself.
      - ycombinatrix 2y ago
        openssh-portable already exists. debian developers tried to be extra clever and it blew up in everyone's collective face.

by guappa 2y ago

ycombinatrix 2y ago

>Can you confidently claim that upstream developers are better at security than debian developers? With respect to the upstream application? Yes, obviously.

lmm 2y ago

> I certainly don't have the capacity to deal with 3794 special snowflakes. It's hardly unique. Every major language other than C/C++ (and Python, but Python is just a mess in general) works like Rust here. If anything I'd say it's the C people who are the snowflakes. > Can you confidently claim that upstream developers are better at security than debian developers? I can confidently claim that upstream has better policies. Debian routinely patches security-critical software without dedicated security review; this predictably lead to disaster in the past and will lead to disaster again. Also the Debian SSL key bug was not just one more CVE on a par with any other. It was probably the worst security bug ever seen in general-purpose software.

guappa 2y ago
> I can confidently claim that upstream has better policies. Debian has thousands of different upstream, you don't even know who they are, how can you claim to know their policies and to have evaluated all of them? Also, all the 1 person projects do not get fixes in a timely manner. As you would understand if there was any amount of reasoning behind your arguments. Are you done making stuff up or must you continue? > Also the Debian SSL key bug 1. Shit happens 2. If you want random data you read from /dev/random, an uninitialised buffer is NOT random. 3. If your example dates to over a decade ago, I'd say the track record is excellent.
- lmm 2y ago
  > Debian has thousands of different upstream, you don't even know who they are, how can you claim to know their policies and to have evaluated all of them? Thousands of upstreams yes, thousands for security-critical software no. > 2. If you want random data you read from /dev/random, an uninitialised buffer is NOT random. That's not what was happening. Now who's making stuff up? > 3. If your example dates to over a decade ago, I'd say the track record is excellent. The worst bug in regular software had to happen at some point in time, it happens to have happened over a decade at all. It's not like Debian's record has been spotless since then.
  - guappa 2y ago
    > Thousands of upstreams yes, thousands for security-critical software no. Everything is security critical. > That's not what was happening. Now who's making stuff up? You, who didn't read the mailing list exchange > The worst bug in regular software had to happen at some point in time ??? How did you classify it? Were there any other contenders? Can you share which contenders were there?
andrewshadura 2y ago
> Debian routinely patches security-critical software without dedicated security review This is untrue. Provide some evidence or withdraw your false claim. Thanks.
- ycombinatrix 2y ago
  They patched openssh without dedicated security review...which directly allowed the xz backdoor debacle. Checks out to me.
  - guappa 2y ago
    If you expect a bsd software to run unpatched on linux… I don't know what to say to you… except to tell you to try and do it yourself.
    - ycombinatrix 2y ago
      openssh-portable already exists. debian developers tried to be extra clever and it blew up in everyone's collective face.