Cargo.lock are also 100% identical with the _orig.tar files uploaded to
the rust-* namespace in Debian by the Debian-Rust team:
https://wiki.debian.org/Teams/RustPackaging
cheers,
kpcyrd
PS: this also works in some cases now:
https://whatsrc.org/artifact/git:64a5f90b44bc845a4c59f37cb49d9b7693cde6b5
12450e02443e16786d3d745b31
A pointer like "instead of `git archive`, run: ..." would already be
helpful, if somebody wants to write a patch, the relevant code location
would be:
https://github.com/kpcyrd/what-the-src/blob/8d9b18f54770a2c2830986af89af15b39c49c70c/src/git.rs#L110-L126
Th
/blake2b:babc1506eca6dc5bd48e58fabfd42502d33b506b2e600b7aa98126a6deb0d68e14dc692abb0ef5079e3ccf710648f0b82fe1b404303d932f2156104c479442ec
I'm interested in adding NixOS as a 5th distribution, but I'm not sure
how to get the relevant data. Help welcome in
https://github.com/kpcyrd/what-the-src/issues/12. The existing rpm
tooling may also work for OpenSUSE but I haven't tried yet.
The site operates fairly co2 efficient (due
ped from source" if autoreconf
is used as part of the build instead of executing some pre-compiled
`./configure` script. This however means that, to compile bash, one
needs to compile autotools first.
curious,
kpcyrd
On 4/18/24 3:45 PM, Chris Lamb wrote:
To that end, what conferences are folks on this list still going to,
and, hopefully, still getting something from? I mean, there must be
some exceptions other than FOSDEM… :)
For me personally, in no particular order:
- The Chaos Communication
April, so it makes sense it's not being mentioned in the report for
March. Sorry for the confusion on my end.
cheers,
kpcyrd
On 4/10/24 12:58 PM, Chris Lamb wrote:
https://reproducible-builds.org/reports/2024-03/?draft
> Reproducible builds developer kpcyrd reported that that the Arch
Linux "minimal container userland" is now 100% reproducible after work
by developers dvzv and Foxboron on the
ource code build process" is clearly just the build process in a
trenchcoat.
cheers,
kpcyrd
in Debian as sole permitted
form of source.
I'd be fine with that.
cheers,
kpcyrd
On 4/3/24 4:21 AM, Adrian Bunk wrote:
On Wed, Apr 03, 2024 at 02:31:11AM +0200, kpcyrd wrote:
...
I figured out a somewhat straight-forward way to check if a given `git
archive` output is cryptographically claimed to be the source input of a
given binary package in either Arch Linux or Debian
what to code review. This is also why I
think code signing by upstream is somewhat low priority, since the big
distros can form consensus around "what's the source code" regardless.
https://github.com/kpcyrd/backseat-signed
The README shows how to verify Arch Linux and Debian build
tioned above.
http://allanmcrae.com/about/
cheers,
kpcyrd
https://www.openwall.com/lists/oss-security/2024/03/29/4
Exciting times
aving achieved reproducible builds first.
cheers,
kpcyrd
ir gitlab that could be used to
track this topic (or work on it):
https://gitlab.kitware.com/cmake/cmake/-/issues/25804
cheers,
kpcyrd
ebian's libnettle[6].
[4]: https://github.com/kpcyrd/repro-env
[5]: https://tracker.debian.org/pkg/rust-repro-env
[6]: https://tracker.debian.org/pkg/nettle
cheers,
kpcyrd
with the build time embedded in it.
Most unreproducible packages fall into on of those buckets. The only
build path related problem in Arch Linux, are randomized filenames or
directory names that sometimes get embedded into the binary.
Anyway, cheers
kpcyrd
hello,
I released a tool recently that I'd like to share with this list:
https://github.com/kpcyrd/archlinux-userland-fs-cmp
It's supposed to be used from a rescue image (any Linux) with an Arch
install mounted to e.g. /mnt. It does the following:
- Open /mnt/var/lib/pacman and extract
for about 6-8€. To document my
build environment I used repro-env[2] together with Arch Linux because
its archive[3] is very reliable and contains all the different Rust
development tools I needed.
[1]: https://github.com/esp-rs
[2]: https://github.com/kpcyrd/repro-env
[3]: https
quot;
(this is a common issue with snapshot.debian.org). The remaining
uncertainty in this space are things like "do we expect old releases to
continue to be reproducible, and if so, for how long". This is a
controversial topic because it would require a public archive of all old
build dependencies (that not every project is willing/able to commit to).
I hope somebody considers this email useful.
cheers,
kpcyrd
e --tags)
% ssh kpc...@some.build.server.example.com "echo $pkgver"
uid=1016(kpcyrd) gid=1021(kpcyrd)
groups=1021(kpcyrd),965(docker),985(users),998(wheel)-1-g7f856c3
%
```
Enjoy
an attempt to get the 2nd issue resolved (before
or during the summit).
The PEP-518 approach is more labour intensive and gives an estimated 1%
improvement from 86%->87% reproducible. The second issue I'm not sure
and can't give an estimate.
cheers,
kpcyrd
2023-07-18 11:32 cmd/govulncheck/doc.go
[kpcyrd@build ~]$ tar tvvf
/var/lib/archbuilddest/srcdest/govulncheck-1.0.0.tar.gz | head
-rw-r--r-- 0/0 63 2023-07-18 09:33 .gitignore
-rw-r--r-- 0/0 995 2023-07-18 09:33 CONTRIBUTING.md
-rw-r--r-- 0/01479 2023-07-18 09
hello list,
I've released v0.3.0 of repro-env:
https://github.com/kpcyrd/repro-env/releases/tag/v0.3.0
It removes the need for a working shared-mime-info environment, the only
runtime dependencies are now:
- Linux unprivileged user-namespaces enabled
- podman installed
- catatonit installed
github.com/kpcyrd/repro-env
It works by adding two more files into your git repository that work
together like Cargo.toml/Cargo.lock or package.json/package-lock.json:
- **repro-env.toml**: this describes the environment you're aiming for,
eg. "the latest debian bookworm, with rust an
essary
source code here:
https://github.com/kpcyrd/archlinux-linux-reproducible/
This is the patch:
https://github.com/kpcyrd/archlinux-linux-reproducible/commit/19f4a7fa430292ab29c22bb58e17fddb4fbf39e0
Also 'thank you' to Michael who sent me an email off-list to help me
with instructions
pinned by their sha256sum, so it's very clear
what should be reviewed, with no ambiguity of some .gitignore being
present or absent.
cheers,
kpcyrd
diff (that would reveal my
backdoor). If I intentionally introduce some benign difference in the
semantic diff it's picking that up as the reason for a mismatch and
moves on (leaving my non-benign changes unreported).
https://twitter.com/kpcyrd/status/1575080558572449792
On top of developme
"GCC: (GNU) 13.1.1
20230429". And obviously to change the binary output is the whole point
of releasing a new compiler version. Linux distributions are using
buildinfo files for this, I'm not aware of any github native solutions
for this.
I hope somebody considers this useful.
Cheers,
kpcyrd
ing is still unclear!
Cheers,
kpcyrd
On 2/2/23 21:14, Chris Lamb wrote:
Please review the draft for January's Reproducible Builds report:
There was a recent update on rb-general@ by Akihiro Suda about
SOURCE_DATE_EPOCH in BuildKit v0.11 that I consider very noteworthy
(although it was technically in February). :)
n "Who is
involved?" on the website, having results to show is a much higher
involvement than having a manual somewhere.
PS: vagrant, please get an irc bouncer.
cheers,
kpcyrd
ry to work around this the same way
https://github.com/chainguard-dev/apko does, by manually creating a
container .tar.
cheers,
kpcyrd
00d302bc52d0d9d5a3d4738bb525066c710
I don't know if there's some kind of gzip standard that could be used to
align the git internal gzip implementation with gnu gzip.
I'm not saying this is necessarily a bug or regression but it makes it
harder to reproduce github tar balls from a git repository. Just sharing
what I've debugged. :)
cheers,
kpcyrd
ohai!
I blogged about a new tool[1] that can be used to verify a tarball from
a signed git tag, while still pinning the sourcecode with >= sha256sum:
https://vulns.xyz/2022/05/auth-tarball-from-git/
Let me know what you think - that's all,
kpcyrd
[1]: https://github.com/kpcyrd/auth-tarb
hi!
I've released a tool that pulls a Package.xz binary package index, then
parses the html of the https://buildinfos.debian.net/ directory listings
until it finds one that matches the Package in Package.xz.
https://github.com/kpcyrd/rebuilderd-debian-buildinfo-crawler
This is a workaround
shoutout to @jvoisin, @SantiagoTorres and @repi for their
contributions. <3
[1]: https://github.com/kpcyrd/rebuilderd
[2]: https://github.com/sponsors/kpcyrd
cheers,
kpcyrd
hi!
I've released rebuilderd v0.16.3, this release is mostly refactoring to
support "build groups", meaning it's now possible to have one build
reproduce multiple artifacts at once.
The full changelog for the 0.16.x series can be found at:
https://github.com/kpcyrd/rebuilderd/re
any questions.
Thanks!
[1]: https://github.com/sponsors/kpcyrd
[2]: https://github.com/kpcyrd/rebuilderd
hi!
I've released rebuilderd v0.15.0, all instances that we're aware of have
already upgraded.
Changelog can be found here:
https://github.com/kpcyrd/rebuilderd/releases/tag/v0.15.0
I've published an intro on how rebuilderd works and a walkthrough on how
to write custom integrations on twitter
hi!
I uploaded a github repo that distributes a Hello World in various
formats (ELF binary, Docker image, 3rd party(!) Arch Linux package) and
documented every file and command needed to reproduce the artifacts
bit-for-bit:
https://github.com/kpcyrd/i-probably-didnt-backdoor-this
I'm not very
On Mon, Aug 02, 2021 at 11:07:21AM +0100, Chris Lamb wrote:
> Really appreciated. As a reminder, we're looking for entities that are
> participating in some way in reproducible builds or have done so in
> the past. This could be technology projects, organisations,
> individuals, etc. and indeed
Hello!
One of the rebuilderd based Arch Linux rebuilders flagged a design issue in
grub that likely affects all distros:
│ ├── usr/share/man/man8/grub-install.8.gz
│ │ ├── grub-install.8
│ │ │ @@ -112,15 +112,15 @@
│ │ │ is only available on EFI.
│ │ │ .TP
│ │ │
On Sat, Jan 30, 2021 at 12:22:55PM +, Holger Levsen wrote:
> On Fri, Jan 29, 2021 at 05:39:01PM -0500, David A. Wheeler wrote:
> > What would be especially helpful for accelerating deployment of verified
> > reproducible builds in a few key places? E.g., what tools, infrastructure,
> >
On Thu, Dec 10, 2020 at 02:51:16PM +, Chris Lamb wrote:
> Chris Lamb wrote:
>
> > Please review the draft for November's Reproducible Builds report:
>
> This has now been published; many thanks to all who contributed.
>
> Please share the following URL:
>
>
On Tue, Nov 24, 2020 at 02:05:55PM -0600, jathan wrote:
> On 23/11/2020 15:23, Holger Levsen wrote:
> > or you could maybe help with getting this archlinux rebuilderd set up
> > set up on r-b.o infrastructure?
>
> It is a good proposal to help with
> the Arch Linux rebuilder set up on r-b.o
Hello!
Since the list is fairly low traffic and most discussion happens in the
irc channel anyway I'd like to suggest moving most, if not all,
notifications by KGB-{1,2} into a different channel.
I suspect that only very few people actually use them and valuable
discussion disappears quickly
to restart the
daemon and your workers after updating, rebuilderd-worker 0.4.0 can't be used
with a 0.5.0 rebuilderd daemon.
Instructions to setup your own rebuilder can be found in the Arch
Wiki[5].
There are pre-compiled binaries available for debian at:
https://github.com/kpcyrd/rebuilderd
I'm a bit short on time, sorry in advance if the email is a little short/blunt:
- What was the original motivation of putting the size and checksum of the
package into the buildinfo file? We aren't tracking this info in Arch Linux
and it turned out we didn't need those fields to implement a
On Wed, Jun 10, 2020 at 11:51:44AM -0400, Leo Wandersleb wrote:
> Sure but I found it confusing in combination with the quorum logic. If I trust
> my 12 sock puppets, I can reach any quorum that only requires 5 signatures.
> Some
> slightly stronger concept of identity is needed if you go by a
On Wed, May 20, 2020 at 02:17:56PM +, Holger Levsen wrote:
> > The buildinfo is an output of the initial build and becomes an input for
> > the rebuilder, but a rebuilder is always going to use the official
> > buildinfo when verifying the official package. I'm not sure if the
> > buildinfo of
On Thu, May 14, 2020 at 02:10:04PM +0200, Marek Marczykowski-Górecki wrote:
> > This is an implementation detail, isn't it? A buildinfo wouldn't be
> > required if
> > you are in an environment where the build environment doesn't change. But in
> > many cases, this isn't the case. Dependencies we
On Wed, May 13, 2020 at 09:39:40AM +0200, Arnout Engelen wrote:
> This seems useful, though I think it is helpful to describe the
> relationship between
> the 'buildinfo' and such a 'rebuild result'.
>
> It is already common practice for a reproducible build to record a
> 'buildinfo' with
>
I think it makes sense to clarify who's supposed to consume the output,
almost all of the data in there is only useful for plumbing by r-b and
distro people and I don't think that needs to be signed beyond transport
security.
The target "audience" of a rebuilder are package managers like pacman
for the "hands-off, everything just works™"
experience.
The setup documentation can be found in the Arch Linux wiki[1].
[1]: https://wiki.archlinux.org/index.php/Rebuilderd
The code can be found here:
https://github.com/kpcyrd/rebuilderd
https://github.com/archlinux/archlinux-repro
Pl
that it's considered experimental (and shouldn't be exposed
to the internet yet).
[2]: https://github.com/kpcyrd/rebuilderd
The project consists of 3 components:
- rebuilderd: the brain that keeps track of the pkg states, queue and
hands out tasks to workers
- rebuilderd-worker: receives a task from
I personally joined the project because I'm interested in independent
verification of binaries, from the point of view as both a publisher and
a user of binaries.
While I think the other efforts are very valid and important as well and
efforts building on top of each other, I'd rather keep this
57 matches
Mail list logo
