[rb-general] distributed package verification system

[Bernd Hopp]

Hi Holger, thanks for your answer. You brought up two important points that
I hope to answer now.
One is the question on feedback, or more generally 'how will it be handled
when the server reports a different hash from what the user has
downloaded/build'. I agree that there should be some sort of reporting
system but I'm not quite sure how this should look like. The problem is
that for forensic analysis, the server would need the actual package that
the client downloaded from the repo but that would eat up a lot of bandwith
and storage space on the server. One idea I had was to let the client
download the 'reference package' ( the source build of the server ) and
then let the client create a bsdiff/courgette diff from it, which it can
then upload to the server again, for further analysis. The client can then
install the reference package if it wants to, and let the server ( or the
operator behind it ) figure out how the packages differ.

As for the packaging systems, dnf and apt are the systems I would like to
support initially, as these are the most widespread ones. most of the
client side business logic should stay in the rpfld daemon (
https://github.com/berndhopp/rpfl/tree/master/client/rpfld ), so I hope
that the plugins can stay lean.

best,
Bernd

On Wed, Jun 1, 2016 at 4:08 PM, Holger Levsen <holger at layer-acht.org> wrote:

> Hi Bernd,
>
> thanks for reaching out to us!
>
> On Tue, May 31, 2016 at 09:45:11AM +0000, Bernd Hopp wrote:
> > I'm looking for developers and build experts to join my project for
> > distributed package verification rpfl (github
> > <https://github.com/berndhopp/rpfl>) and would like to ask you to give
> me a
> > hand at this. Goal of the project is to give package management systems
> the
> > opportunity to verify that a downloaded package corresponds to its
> publicly
> > available source code.
>
> very nice!


> > To achieve this, a server will create hashes of the
> > packages that it had previously build from source and sign them via
> > ed25519; this signature is then be used by the client to check if the
> > downloaded package is the same as the package resulting from a build from
> > source.
>
> I think it would also be good if the server could get these hashes from
> other builders (just different machines or entirely operating by
> different entities) and it should be possible to store several different
> hashes for a given source. Because unreproducible software exists today.
>
> Another idea, for the Debian usecase, is also to have several people
> report the checksums they see, so that it becomes possible to see
> if+when one gets a different checksum than everybody else



> The project is currently proof-of-concept and needs some work at the
> server


> > code, especially in the area of buildsystem-integration. Also, plugins
> fro
> > package management systems need to be developed to really make use of it.
>
> What system are you targeting at the moment, btw? IOW: do you have plans
> for integration with apt or dnf or $anyothertool?
>
> > If you are interested in participating or if you know somebody who might
> > be, please don't hesitate to ask me any questions about the project or
> > next steps.
>
> please continue sharing news about this project on this list! also, you
> might want to join #reproducible-builds on irc.oftc.net if you are on
> IRC…
>
>
> --
> cheers,
>         Holger
>
> _______________________________________________
> rb-general at lists.reproducible-builds.org mailing list
>
> To change your subscription options, visit
> https://lists.reproducible-builds.org/listinfo/rb-general.
>
> To unsubscribe, send an email to
> rb-general-unsubscribe at lists.reproducible-builds.org.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.reproducible-builds.org/pipermail/rb-general/attachments/20160601/4cdc2c86/attachment.html>