On Tue, Nov 05, 2019 at 09:12:33AM -0500, Eli Schwartz wrote: > On 11/5/19 9:03 AM, Allan McRae wrote: > > On 5/11/19 11:58 pm, Morten Linderud wrote: > >> On Tue, Nov 05, 2019 at 11:54:34PM +1000, Allan McRae wrote: > >>> When creating or modifying repo tarballs, place a .TIMESTAMP file with > >>> seconds since epoch in it. This will be used in the future to enable > >>> rejecting databases older that a given threshold. > >>> > >>> Also skip reading the .TIMESTAMP file in sync_db_populate(). > >>> > >>> Signed-off-by: Allan McRae <[email protected]> > >>> --- > >>> > > > > <snip> > > > >>> diff --git a/scripts/repo-add.sh.in b/scripts/repo-add.sh.in > >>> index caf1232d..c87409f1 100644 > >>> --- a/scripts/repo-add.sh.in > >>> +++ b/scripts/repo-add.sh.in > >>> @@ -526,6 +526,7 @@ create_db() { > >>> TAR_OPT=$(verify_repo_extension "$REPO_DB_FILE") > >>> # $LOCKFILE is already guaranteed to be absolute so this is safe > >>> dirname=${LOCKFILE%/*} > >>> + timestamp=$(date +%s) > >> > >> This should probably utilize SOURCE_DATE_EPOCH or something equivalent? > >> > >> timestamp=$(date --date="@${SOURCE_DATE_EPOCH:-$(date +%s)}" +%s)) > > > > Why? I can see no reason why it should... > > I don't either see value in "reproducible builds" for the actual state > of the database. It's just a series of plaintext pointers to some other > (hopefully reproducible) packages. > > If we actually did want to respect SOURCE_DATE_EPOCH, we'd need to do a > lot more, like doing that for the bsdtar metadata (both file timestamps > and file owners, probably sort files too, etc.) but again, I don't see > how this protects the supply chain.
Hmm, should probably discuss the threat model or attack vectors in #archlinux-reproducible. -- Morten Linderud PGP: 9C02FF419FECBE16
signature.asc
Description: PGP signature
