suy

joined 1 year ago
[–] suy@programming.dev 1 points 6 months ago

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.

[–] suy@programming.dev 11 points 6 months ago (2 children)

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.

[–] suy@programming.dev 39 points 6 months ago

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
[–] suy@programming.dev 18 points 7 months ago (1 children)

I'm not fully sure what the intent of the joke is, but note that yes, it's true that a header typically just has the prototype. However, tons of more advanced libraries are "header-only". Everything is in a single header originally, in development, or it's a collection of headers (that optionally gets "amalgamated" as a single header). This is sometimes done intentionally to simplify integration of the library ("just copy this files to your repo, or add it as a submodule"), but sometimes it's entirely necessary because the code is just template code that needs to be in a header.

C++ 20 adds modules, and the situation is a bit more involved, but I'm not confident enough of elaborating on this. :) Compile times are much better, but it's something that the build system and the compilers needs to support.

[–] suy@programming.dev 10 points 7 months ago

Precisely, Gary Bernhardt has given a talk on ideology. I don't think he's precisely someone who thinks in absolutes. It's just preaching that some stuff is (probably) used more than it should. I've seen way, way, way worse projects that over engineered things and made things slow and unmanageable, than the opposite. Of course, everyone has seen different things, and our perceptions are amplified and biased by that.

[–] suy@programming.dev 6 points 8 months ago

The github project page is for developers, and Github already gives you tons of ways to make a user website. Don't ask your users to visit github.com/group/project, make them visit group.github.io/project, like any sane person.

Same with Gitlab, BTW.

And if you don't like the full static site, use the wiki, or guide your users in the first paragraphs of the README so they find the user information if they must.

[–] suy@programming.dev 6 points 10 months ago (1 children)

Sorry, could you clarify what you mean? I don't see the difference. Isn't the author complaining about Canonical for the policy enforcement?

[–] suy@programming.dev 27 points 10 months ago

Thanks. I should have linked to that myself, perhaps.

view more: ‹ prev next ›