3 ms·

As I posted above, we have a build service that does this automatically for you. It takes maybe 30 minutes to create a few spec files, and now it's supported by

by cyphar 9y ago

As I posted above, we have a build service that does this automatically for you. It takes maybe 30 minutes to create a few spec files, and now it's supported by a bunch of different distributions. You can then point your users at the repo (or mirror the repo if you prefer). Also OBS lets you create forks of projects that just inherit the unmodified packages (and said forks can also be cross-host so you don't need to self-host a whole distribution). I agree that doing everything I mentioned manually is hard, that's again why I said that distributions have solved this problem and made it easy.

cm2187 9y ago
But who would use the build service? The consumer of the software or the publisher? [edit] also that protects you against malware injecting binaries in an executable when compiling it, but not from malware injecting code into the source code of the executable.
- cyphar 9y ago
  > But who would use the build service? The consumer of the software or the publisher? Publisher. A user could (if they were really paranoid) rebuild the packages locally, with two or three commands. > Also that protects you against malware injecting binaries in an executable when compiling it, but not from malware injecting code into the source code of the executable. You can download the source code that OBS used (both as a src RPM generated by the builder and the OBS repo that the builder was given read-only access to), and OBS supports cryptographic signatures of the originating source (with gpg-offline keys to avoid WoT attacks). If your developers are using sane source control practices (use GPG keys for every commit, but especially tags) then you are protected against that too. Of course, reproducible builds is something that would solve this problem even better (protecting against attacks on OBS that cause it to add source that are not in the repo). As a side point, our threat model doesn't fully trust the nodes compiling the software so such attacks are fairly limited in scope (but I'm not a developer of OBS so I'm really not the right person to be asked these questions).

by cyphar 9y ago

cm2187 9y ago

But who would use the build service? The consumer of the software or the publisher? [edit] also that protects you against malware injecting binaries in an executable when compiling it, but not from malware injecting code into the source code of the executable.

cyphar 9y ago
> But who would use the build service? The consumer of the software or the publisher? Publisher. A user could (if they were really paranoid) rebuild the packages locally, with two or three commands. > Also that protects you against malware injecting binaries in an executable when compiling it, but not from malware injecting code into the source code of the executable. You can download the source code that OBS used (both as a src RPM generated by the builder and the OBS repo that the builder was given read-only access to), and OBS supports cryptographic signatures of the originating source (with gpg-offline keys to avoid WoT attacks). If your developers are using sane source control practices (use GPG keys for every commit, but especially tags) then you are protected against that too. Of course, reproducible builds is something that would solve this problem even better (protecting against attacks on OBS that cause it to add source that are not in the repo). As a side point, our threat model doesn't fully trust the nodes compiling the software so such attacks are fairly limited in scope (but I'm not a developer of OBS so I'm really not the right person to be asked these questions).