I’d have to dig it, but I think it said that it added the PID and the uninitialized memory to add a bit more data to the entropy pool in a cheap way. I honestly don’t get how that additional data can be helpful. To me it’s the very opposite. The PID and the undefined memory are not as good quality as good randomness. So, even without Debian’s intervention, it was a bad idea. The undefined memory triggered valgrind, and after Debian’s patch, if it weren’t because of the PID, all keys would have been reduced to 0 randomness, which would have probably raised the alarm much sooner.

no more patching fuzzers to allow that one program to compile. Fix the program

Agreed.

Remember Debian’s OpenSSL fiasco? The one that affected all the other derivatives as well, including Ubuntu.

It all started because OpenSSL did add to the entropy pool a bunch uninitialized memory and the PID. Who the hell relies on uninitialized memory ever? The Debian maintainer wanted to fix Valgrind errors, and submitted a patch. It wasn’t properly reviewed, nor accepted in OpenSSL. The maintainer added it to the Debian package patch, and then everything after that is history.

Everyone blamed Debian “because it only happened there”, and definitely mistakes were done on that side, but I surely blame much more the OpenSSL developers.

Is it, really? If the whole point of the library is dealing with binary files, how are you even going to have automated tests of the library?

The scary thing is that there is people still using autotools, or any other hyper-complicated build system in which this is easy to hide because who the hell cares about learning about Makefiles, autoconf, automake, M4 and shell scripting at once to compile a few C files. I think hiding this in any other build system would have been definitely harder. Check this mess:

  dnl Define somedir_c_make.
  [$1]_c_make=`printf '%s\n' "$[$1]_c" | sed -e "$gl_sed_escape_for_make_1" -e "$gl_sed_escape_for_make_2" | tr -d "$gl_tr_cr"`
  dnl Use the substituted somedir variable, when possible, so that the user
  dnl may adjust somedir a posteriori when there are no special characters.
  if test "$[$1]_c_make" = '\"'"${gl_final_[$1]}"'\"'; then
    [$1]_c_make='\"$([$1])\"'
  fi
  if test "x$gl_am_configmake" != "x"; then
    gl_[$1]_config='sed \"r\n\" $gl_am_configmake | eval $gl_path_map | $gl_[$1]_prefix -d 2>/dev/null'
  else
    gl_[$1]_config=''
  fi

I’ve wanted to start a project in Rust, but for the ideas that I have (and the time that I have for a hobby project, as for work it’s rarely starting a new one, but continuing and existing one), Rust seemed a viable, but not ideal alternative to just doing it all in C++, for which I already have enough knowledge and very well proven libraries. I will look again soon, and I will keep looking because eventually something will surely click, it’s just that so far, the time has not been right.

Note that my point is not that it’s unusable for everyone. Just that it’s false that “some people just can’t seem to let [C or C++] go”, as the previous comment said. I can’t let go something that works well for something that doesn’t, given the projects that I have to work on.

It’s just time to move on from C/C++, but some people just can’t seem to let go.

The Rust community has 2 websites that I keep periodically checking: Are we game yet? and Are we GUI yet?. The answers on those sites are respectively (as of February 2024, when this comment is written) “Almost. We have the blocks, bring your own glue” and “The roots aren’t deep but the seeds are planted”. I’ve seen the progress in Bevy and Slint, but it’s still the same, those websites don’t change, and my situation WRT to making a Rust project for fun or work it’s the same.

I’ll be happy to start doing Rust projects whenever I get the chance (which will be when it’s a sufficient tool for my use cases). But I’m tired of smoke sellers.

The very first moment that I had to use JSON as a configuration format, and I was desperate to find a way to make a long string into a JSON field. JSON is great for many things, but it’s not good at all for a configuration format where you need users to make it pretty, and need features like comments or multi-line strings (because you don’t want to fix a merge conflict in a 400 character-wide line).

Doesn’t YAML have a (seldom used) feature of a start and end of document marker? The “YAML frontmatter” that a few markdown documents have, uses this.

Radon, the “handwriting” one, seems like if someone wanted to have Comic Sans but for code.

I heard the rumor that Linux desktop environments use it too. Now hopefully multimedia apps with 3 letters like VLC and OBS can adopt it too.

j/k