taviso

Can you explain the wlroots issue?

You have the source, you have a binary that you've produced from that source, and you have a binary that someone else claims was produced from that source.

You know without doubt that the binary that you produced was built from the source code, because you built it.

I'm asking, why not stop there? You have a binary that you can safely consider "verified", what does it matter if it's bit-for-bit identical to any other binaries?

Why didn't you just build from source, and then use those binaries?

What did the reproducibility add?

Makes me think of WOLK, a popular kernel patchset back in the early 2000s. It didn't feel like a real kernel release until the WOLK patch was ready.

Hah, I use an old DOS grammar checker called Grammatik.

It works well enough for me, I use it with mutt instead of ispell. Naturally, it's 100% offline.

I made a (terrible?) unboxing video a while ago: https://www.youtube.com/watch?v=6DMlaJ-ROXc

That's really cool. I made a terrible one for SHA1 years ago, yours is 1000x better.

https://lock.cmpxchg8b.com/sha1/visualize.html

I read a paper at the time where someone described a tool they made to find a near-collision, they explained they were just flipping bits and visually observing the affects. That sounded kinda fun, but they didn't release it, so I tried to replicate it from their description!

Hmm, how would you replicate the alignment operation they show in the gif using vim? I couldn't immediately think of how to do it.

I guess you could select the block, then maybe s/\>\s\</\=repeat(' ', 20 - col('.'))/g?

That doesn't feel like the right solution though... maybe a macro, something like qa^wi<Tab><Esc>q then visual select and :norm@a? I dunno.

No, I always use gdb :)

It also has a persistent history, variables, functions, base conversion, etc. I guess it doesn't have unit conversion or a math library, but it's a great programmers calculator.

It's also worth noting that if you're caught playing games like this, there is really no way to explain your actions that would avoid serious consequences.

If however, you used the "bugdoor" method, you can plausibly deny any malicious intent and you will absolutely get away with it.

There are lots of ripgrep recommendations in the comments, but an interesting alternative to grep specifically for code browsing might be weggli by my teammate Felix!

https://github.com/googleprojectzero/weggli

I've (probably?) found more linker vulnerabilities than anyone else, but don't really understand your argument. I definitely understand library search path vulnerabilities (I've literally found bugs in $ORIGIN parsing, e.g. CVE-2010-3847 was one of mine!).

We think security updates don't break API/ABI because they're backported to all previous major versions that are still actively supported. This isn't "thoughts and prayers", it's work that the packagers and maintainers do. I can't tell you how useful being able to fix a vulnerability in every program is, just think of updating every application that uses libpng on your desktop, or every server application that uses OpenSSL.

I just can't imagine wanting to give that up, because of name mangling ABI issues!

Hmm, it's okay, but just leaves some blank space on the right.

I tried to fix it, adding these to yours seems to work okay:

    youtube.com###related:upward(#secondary)
    youtube.com##:root:not(:fullscreen) video:matches-css(left: 0px):style(object-fit: fill!important; width: 100%!important; height: auto!important;)

I do something similar, I noticed that a link to a tweet in an article that I'm reading will always result in me clicking through and then wasting time catching up.

I used this filter, it makes twitter links look like normal text:

    ##a[href*="twitter.com"]:style(pointer-events: none!important; text-decoration: inherit!important; color: inherit!important)

That's funny, I had this tab open this weekend while I was trying to make a silly terminal game, where each sprite is an ncurses window. I didn't really make much progress, but got the physics and sprite drawing working.

https://lock.cmpxchg8b.com/img/ncurses.gif

Clever, but I'm curious why you don't use VLOOKUP?

It's simpler, and Lotus 1-2-3 doesn't have MATCH! :-)

I think something like this would work...

    (income-@VLOOKUP(income,table,1))*@VLOOKUP(income,table,3)+@VLOOKUP(income,table,5)

I've had to endure dirty tricks, even threats and fabricated accusations from Microsoft. It's not a whole lot of fun.

Thankfully no black vans or ominous packages in the mail (yet).

PTT is part of the CPU, no external TPM module is necessary. PTT is Intel's implementation, AMD have something similar called fTPM.

You do not need any external module on machines with fTPM/PTT support (i.e. if you bought it in the last few years).

That doesn't sound right, search around in the BIOS for "Platform Trust Technology" or "PTT". If it's disabled, change it to enabled.

> People don't do kernel reviews themselves. They just use the official kernel, and when someone finds a bug (or spots otherwise bad code), they notify the community.

There's a big difference here. When a vulnerability is found in the Linux kernel, that doesn't mean that you were compromised.

If a build was found to be malicious, then you definitely were compromised and it's little solace that it was discovered after the fact. This is why package managers check the deb/rpm signature before installing the software, not after.

I would point out that is literally what ccache (and Google goma) does, but doesn't require deterministic builds. Instead, it records hashes of preprocessed input and compiler commandlines.

They don't make any security claims about this, it's just for speeding up builds.

I don't really have any complaints about using deterministic builds for non-security reasons, but the number one claim most proponents make is that it somehow prevents backdoors. Literally the first claim on reproducible-builds.org is that build determinism will prevent threats of violence and blackmail.

> With the reproducible build, you can start using the untrusted binary while you are still building your trusted one.

That's not how it works, you have to reproduce it before it becomes trusted.

> You can also have ten people on the internet verify the untrusted binary.

Sure, then we have to build a complex consensus system that introduces a bunch of unsolved problems. My opinion is that this just isn't worth it, there is practically nothing to gain and it's really really hard.

> As a developer, it would be quite reassuring to build my binary (which I already do for testing) and compare the hash with the one from the CI server to confirm nothing has been tampered with.

That makes sense! However, this is not a good argument for reproducible builds, because you can already do that today.

You already have to build a trusted binary locally for testing right? You're dreaming of being able to compare that against the untrusted binary so that you can make sure it's a trusted binary too - but you already have a trusted binary!

Okay - but it's a hassle, you don't want to have to do that, right? Too bad - reproducible builds only work if someone reproduces them. You're still going to have to replicate it somewhere you trust, so you gained practically nothing.

> I really don't understand this argument; compromised infrastructure probably shouldn't be a regular occurrence, and even if so, automated killswitches seem like the vastly more preferable option, no?

I'm pointing out how complex implementing reproducible builds is. It introduces a bunch of really hard unsolved problems that people are very handwavy about.

Who will do the reproducing? You say that users won't be able to do it. That makes sense, because if they could, then reproducible builds would be useless! However, you also say they will be able to check if a build server is compromised at any time. In order for both of those claims to be true we will have to design and build a complex consensus system operated by mutually untrusted volunteers. That's really hard, and seems like it provides a pretty negligible benefit.

> It has nothing directly to do with violence against developers, that's taking many leaps.

It is literally the very first claim on the front page of https://reproducible-builds.org.

I don't really understand what you're saying.

If you're saying "reproducible builds are reproducible", then that is obviously true, but the question is what is the benefit?

Some people claim that the benefit is that there will be less incentive to threaten developers with violence, and I'm saying that's nonsense. If you cut through the nonsense, there are some modest claims that are true, but doing reproducible builds properly is very complicated and the benefit is negligible.

I think the workflow you're proposing is to take some trusted source code, then compile it to make a trusted binary. Now compare the trusted binary to the untrusted binary provided by the vendor - If they're the same - then it must have been made by an uncompromised toolchain.

That does require reproducible builds, but here is how to do it without reproducible builds:

Take the trusted source code, then compile it to make a trusted binary. Now put the untrusted binary in the trash, cause you already have a trusted binary :)

> Is it technically pointless if you view it as a check on your own build, rather than a check on the work of others?

That depends, I think it's difficult and mostly still pointless. I wrote about this a bit in the blog post I linked to. It's a big trade off, for questionable benefit.

> Wouldn't reproducibility be necessary for those systems to work well most of the time?

Yes, there are definitely some good non-security reasons to want deterministic builds. My gripe is only with the security arguments, like claims it can reduce threats of violence against developers (!?!).

Every major vendor has vulnerabilities introduced all the time, by accident! No talent is necessary to introduce a bugdoor, just malice.

You can already verify that a toolchain wasn't backdoored today, reproducible builds aren't necessary for that.

The point was that a reproducible build doesn't mean you don't have to trust the developer.

Build servers rebelling was just an example of the additional complexities and attacks that it introduces, for very negligible benefit.