Alright for one I am not entirely sure what "reproducible builds" means, is it more of a buzz word? I read an article about how Debian is pushing to make all of their packages reproducible. In my mind, it means that I can actually get the source code of a piece of software that is on my computer and build it exactly the same way the "debian" devs did it? SlackBuilds would already allow this correct? I also found a PDF that states Slackbuilds support Reproducible Builds, http://www.slackware.com/~mozes/docs...esentation.pdf


Thank you again guys for responding and helping me, I really appreciate it!

I use slackrepo.

https://idlemoor.github.io/slackrepo/index.html

i use sbopkg

http://sbopkg.org

You need to understand *why* reproducibility is a thing.

The reason why other distributions are seeking reproducibility is trust. In a post-Snowden world, end users want to know that Red Hat's binaries or Suse's build farm have not been subverted. One way to do that is for end users to be able to verify that, if they want to, by building from source and getting a bit-identical result.

Historically, because of the way executables are created and distributed, and because of the flat memory model, Unix has never seen that as a problem. For example, every Slackware package is a tar archive, and every tar archive contains time-stamps, and therefore two packages will always be different unless the time-stamps are fraudulent. Time-stamps are only one example; there are lots of other sources of nondeterminism, as documented by the Debian reproducibility project. Read the details for yourself.

Currently there are no distributions that are 100% reproducible. Even with Debian, this is not in the distro. It's a Debian based research project with a $200,000 dollar budget.

Does that mean we have a problem with trust in Slackware? No, for two reasons.

(1) Slackware's binary packages are built and signed by one man in one place, and from observation Mr Volkerding would seem to be one of the least likely people on the planet to sell out or be compromised.

(2) Everything you get from SlackBuilds.org is built from source yourself, and you can trust yourself. In this sense, as you say, SlackBuilds solve the trust problem. They don't solve the reproducibility problem, but they do make the reproducibility problem irrelevant.

And that's why nobody here is bothered with chasing reproducibility. Maybe it will trickle through via gcc, binutils etc. That's years ahead. We can wait.

Yes, in the sense that your computer is a universal Turing machine and can do anything that any other universal Turing machine can do. But "exactly the same way the debian devs did it" means your universal Turing machine has to run Debian, not Slackware. (duh)

The first slide is from 2005, before the word 'reproducible' took on the specialised meaning that it has today. Protip: always look for a date.

8 members found this post helpful.

What I meant by "reproducible" is that there's a known recipe that can be used again. The intention is that each time you build a package from a script, you get an identical result -- but it's not necessarily going to happen: the output of the package may not be the same if you built it versus when it's built by Patrick. The reason is that the environment -- the OS -- changes (package upgrades, removals, additions), and unless you build all of the packages in exactly the same order as Patrick did, then your package may or may not link against a library -- depending on whether it was installed or not at the time; or perhaps some documentation may not be built because the tool to build it was not present or could not understand a newer format of documentation.
I see this a lot with the ARM port during the large update batches that appear. I'll often get to a 1/3 of the way through (following the build order and notes Patrick keeps aside for us) and find that something won't build and I have to skip up and then back down the list rebuilding or upgrading packages out of order just to get past it, despite using the exact same build order. I don't look into it much since it's not worth it, and once I'm done, all of the packages in a batch are re-built in several passes before they're stamped as done. Now that almost all of the packages in the ARM port have been rebuilt, I wouldn't be surprised if some have different functionality and/or slightly different content to the x86/64.

Summary: there is no way to do a reproducible build in Slackware as it is.

1 members found this post helpful.

To get Slackware to be self duplicating requires that you need to do a lot of work introducing more patches, reworking scripts, introduce dependency check triggers for early core builds and final builds, and then test packages as you go.

It can be done, but in Slackware's current state the answer is no. You can however take an existing Slackware system and rebuild each individual package against a complete system without any problems, at least in theory.

There are a few efforts to get Slackware self duplicating but it is mostly experimental, unsupported, unofficial, and mostly in its early trials. It would be nice to have a system that can self-reproduce to audit builds for checking package reproduction and check for dependency related problems, but it's a lot of work. I can't say if the gains are worth it, but as a tool it could be used to identify a problem with packages, packaging, dependency issues, or even if a package is incompatible with a system.

Sorry I left you out; I should have mentioned you too as someone whose binaries we can trust absolutely; especially after you posted pictures of your build farm

Introducing more patches? What for? Some older packages no longer build with the recent tool chain, but it's hardly any - about 3 or 4 -- I know since I just rebuilt the entire set for ARM a few weeks ago.
Reworking scripts? Why? Only necessary if you need to add a work-around or to add a FTBFS patch. Again, largely unnecessary in my experience.


Slackware is built on a full installation, but unless you know the build order Patrick used then you'd never know whether you came close to replicating what the official tree is without doing a lot of analysis; and even if you did (as I did for some parts), it doesn't mean you can follow it unless you're using Slackware proper as your build environment (rather than your own rebuilt Slackware).

Sometimes there are work-arounds applied during the build process which are not noted anywhere, which further adds to the inability to reproduce exactly what it is.

Most everything now consists of updating existing packages against the existing tree. But to rebuild everything from scratch using a cross-compiler like LFS or Gentoo Stage 1, it would require extra work, and this could, but doesn't necessarily get limited to patches, special buildscripts for the core, rebuilds after the final installation, etc.

If you've ever tried to build LFS in its completed finalized form, you soon find many packages, to get the full usage of the package, require rebuilds against extra dependencies as you progress through the book and even rebuild packages to resolve a cyclical dependency. This becomes no small task, even with a package manager and enough buildscripts.

Because Slackware in essence is a completed fully dependency resolved system, rebuilding it from Stage 1 is problematic. Even the ARM port was built from scratch, but after the system was effectively completed, all dependencies were resolved resulting in the whole system being completed like the x86 and x64.

The build order is very similar to LFS and Gentoo, and in fact any fresh built system runs the same path.

The OP was not asking about building from scratch.

*laughs*

You have absolutely no idea how I did the ARM port. I'm not sure I ever described how it was done, on the two separate occasions that it was built from the ground up. For the first incarnation there's still stuff lying around, but not for the second (current) incarnation.

Come on, Doctor! All of us known that you used a Sonic screwdriver!

--------------

On topic.

The reproducible builds are essentially the complete (re-)building of the Operating System packages from its shipped sources, as security measure against the "prepared" packages, courtesy of our friendly Men in Black from NSA and other naughty Intelligence Services.

Well, Slackware is not literally capable to rebuild itself (like noted right on by the Team Members), but for a (State) Company, wanting to obtain a paranoid clean variant of Slackware, the Slackware rebuild process is (almost) trivial, The Team working right on the published sources.

Then I suppose that is an: YES, the Slackware native support the "reproducible builds".

So essentially the closest I can get to "reproducible builds" for sake of security, is to compile Slackware from scratch using the provided .SlackBuilds? (if I am really that paranoid I would compile everything myself and not use any other software available lol, but I am not and I don't see myself compiling Slackware also).

EDIT: So what's say, Using checksums vs Reproducible builds? In my mind checksums are the main way to check if a package somewhere is actually the same package from a maintainer and is not a "fake" of tampered with. Whereas Reproducible builds actually check the package's content from the maintainer and from someone who builds their own to check if it wasn't tampered with during compile time?

Dear God you're hard work.

Do you need an example?

Mallory works for Red Hat [*]. His job is to build RPM packages. But (unknown to Red Hat management) Mallory is also working for No Such Agency.

Today, Mallory is building vi.

Mallory takes the vi source. Secretly, Mallory modifies the vi source so that when anyone whose username is Altiris starts vi, vi will trash the root filesystem, which will make No Such Agency happy, and will make Altiris unhappy. Mallory builds the RPM from the modified source. Mallory creates the new vi RPM's checksum.

Mallory sends the new vi RPM to the Red Hat Quality Testing department. The vi RPM passes, because the Red Hat Quality Testing department is not named Altiris, and because the checksum is fine. (The checksum just shows that the RPM hasn't been modified since Mallory created it.) The Red Hat Quality Testing department sends the new vi RPM to the users as an update. The users install the vi RPM. The users are happy because the checksum is fine. The users install it. The users are still happy, except Altiris, who is very very unhappy but has no clue what just happened.

How can this loophole be closed?

One answer: build *everything* yourself from source. That's not a complete answer. If you're bored, read this. It's a better use of your time. Srsly.
Reflections on Trusting Trust

The other answer: Reproducible Builds. If anyone can verify that the original vi source produces the exact same RPM every time, Mallory is screwed. It only needs one person to build the vi RPM independently and compare it to the Red Hat RPM and notice that the Red Hat RPM is different, and to scream blue murder about it. Mallory can't take that risk, not for vi, not for anything. It doesn't need Altiris to build the vi RPM independently; it doesn't really need anyone to actually build any RPMs independently, because Mallory simply can't take the risk of being exposed.

The only problem is that Reproducible Building does not exist yet, not anywhere, except as a research project that is still ongoing. Because of the 'Trusting Trust' attack, it is far more complex than just someone casually rolling their own RPM. Read this: Fully Countering Trusting Trust through Diverse Double-Compiling

Is that clear enough? Or am I just too boring?

6 members found this post helpful.

... Assuming that one have both the skills and the time needed to actually read and understand what the program will do once built, and this for _all_ software in the distribution.

Anyone?

Of course.

Attached Thumbnails