One important point of my suggestion is that the list of keys that are
associated with a repo is signed and verifiable with the same list, but is
distinct from the keys that are trusted to sign repos. Trusted keys are a
superset of keys used in a repo.
This makes verifying parts of a repo more
(This implies different dnf repos with different key sets can coexist on the
same system. So you could also add a new repo to an installation, stop updating
the old repo, and at some point remove the old repo from this installation.)
--
Reply to this email directly or view it on GitHub:
https:
I would expect migration to happen this way:
* a dnf repo has only rpms with only one old signature
* dnf and rpm and distribution-repo-keys package or dns repo metadata for
offering new keys are updated to support the new signature format and include
the new key
* a release cycle happens so peo
I disagree as explained above. If there is a sig you do not understand it
should fail the rpm. If you do not have a key for one it should fail. Sigs for
all specified keys need to always be present and to be in the correct order
otherwise fail.
--
Reply to this email directly or view it on Gi
> But, if we can't be trusted to decode base64 then how are we expected
to read the rest of the rpm? That's like being too afraid to leave the
house because something bad might happen.
The point was not about the correctness of our implementation of base64, but
that the format should have only
@simo5 Example: user wants to check that 3 signatures all do verify. How do
they get them? If they download the rpm from signer No 1, then that one can
withhold the signature from signer No 2. If its a detached signature, that
problem doesn't exist. Or do you have a solution to this?
The signat
Why do you want to keep the signature in the package in v6 instead of moving it
into another file?
That excludes any functionality where unrelated parties offer attestations of
the package. For embedding their signature now they all need to coordinate.
Then how do they deal with one of them pos
I'd like to collect ideas for isolation of packages from each other and
sandboxing or restriction of their capabilities on the system.
Currently many install time actions for rpms require scripts and there are many
directories where placing files can indirectly trigger running code as root.
The
Forgot an additional complication: For rolling distributions were no consistent
snapshot is used for building there is the need for an archive of all previous
builds and a tool that selects the correct versions from the archive as the
buildinfo says.
--
Reply to this email directly or view it
AFAIK that is out of scope for rpm, but in the scope of tools that create build
roots, see
https://github.com/rpm-software-management/rpm/discussions/2654#discussioncomment-9060491
.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussion
In Fedora and openSUSE packages distribution variances are dealt with in the
spec by checking the content of distribution specific macros. These macros are
defined in packages shipped in the distribution and installed in the build
root. So using command line defines is really unusual. See
https
You should try to find out what too is used to build the build root for these
packages and use that if you can.
In both openSUSE and Debian a buildinfo file (though with different syntax) of
the the environment for the build is produced. This specifies environment
variables, packages installed
Proposal 2 looks good to me.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2944#issuecomment-2015549221
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-ma
Had a very old version of rpm around and this worked, I can confirm it is a
regression in rpm.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2965#issuecomment-2015076429
You are receiving this because you are subscribed to this thread
Bernhard mentioned that the size of the rpm stays the same on --delsign, but
should shrink by 1104 bytes. I haven't calculated it myself but the direction
of that looks right and a quick read of the code looks like it should be doing
that (but I would need look much more careful to identify why
**Describe the bug**
rpmsign --delsign leaves behind 0 padding, previously similar problem in
https://github.com/rpm-software-management/rpm/issues/2382 fixed by
https://github.com/rpm-software-management/rpm/pull/2396
**To Reproduce**
Steps to reproduce the behavior:
1. rebuild locally: osc co
@JanZerebecki commented on this pull request.
> @@ -245,6 +245,10 @@ Supplements: (%{name} = %{version}-%{release} and
> langpacks-%{1})\
# Is ignored when SOURCE_DATE_EPOCH is not set.
%clamp_mtime_to_source_date_epoch 0
+# If true, make sure that timestamps in built rpms
+#
Thank you for the detail about pyc, that is important.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2880#issuecomment-1966164234
You are receiving this because you are subscribed to this thread.
Message ID:
I think @pmatilai meant having %source_buildtime with constants of either
`SOURCE_DATE_EPOCH`, `SOURCE_DATE_EPOCH_MTIME`, `macro` or `clock`? I'm ok with
that.
My preferred way would be as few macros or settings, but that is not as
backwards compatible. Only reproducible builds. Build host fiel
> > If a build e.g. embeds SOURCE_DATE_EPOCH in the output, then the output
> > changes every time such a rebuild happens, which can be very often.
>
> It only changes if you change SOURCE_DATE_EPOCH, and if you took the
> SOURCE_DATE_EPOCH from the changelog then it only changes if you change t
@JanZerebecki pushed 1 commit.
e6c047aaba828aba1a0e40f01bf47fd9c05e1487 support reproducible automatic
rebuilds
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2880/files/f539811e90825fb120e8592d80cee7b67ac26e1d..e6c047aaba828aba1a0e40f01bf47fd9c05e1487
You are receiv
> You've effectively created a situation where your builds are not reproducible
> outside of your build system with the build system circumstances that created
> it.
That is incorrect. Pass the same 2 environment variables and it is
reproducible. Same as before, just one additional variable.
T
I'd appreciate to know if this would be merged as is. But perhaps we want to
wait with the actual merge until it was shipped in OpenSUSE and nobody
complained for two weeks. I think it should work as is, but this stuff has so
many parts that yet another problem could be found.
--
Reply to this
Normally automatic rebuilds work, but together with reproducible builds an
undesirable situation may occur. If a build e.g. embeds SOURCE_DATE_EPOCH in
the output, then the output changes every time such a rebuild happens, which
can be very often. This is to be avoided as updating packages witho
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2853
-- Commit Summary --
* Fix link, declarative builds instead of autobuild
-- File Changes --
M docs/manual/index.md (2)
-- Patch Links --
https://github.com/rpm-so
Closed #2677.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2677#event-10462916706
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing list
Rpm
There is also an error in this as OBS increases the second number of release,
like 1.2 -> 1.3 .
Will implement in obs-build instead.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2677#issuecomment-1733740158
You are receiving this beca
Are rebuilds with changed dependencies but unchanged source never done for
Fedora?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2677#issuecomment-1733634320
You are receiving this because you are subscribed to this thread.
Message ID:
@JanZerebecki pushed 1 commit.
873e2c4b7b2958c40aee38d073c0d5d88e4687fe Increment build date every release
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2677/files/d29950aad75b870ade68b9f0eb0918c2d80514f7..873e2c4b7b2958c40aee38d073c0d5d88e4687fe
You are receiving th
See https://github.com/rpm-software-management/rpm/pull/2677
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2676#issuecomment-1731262349
You are receiving this because you are subscribed to this thread.
Message ID:
Closed #2676 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2676#event-10446356005
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint m
for %source_date_epoch_from_changelog to avoid breaking rsync without
--checksum or anything else that relies on modification time stamp of files to
detect changes. Only use the number at the start of the string for this. To
ensure clamping mtime still works the date needs to be in the past, so
`SOURCE_DATE_EPOCH` (see
https://reproducible-builds.org/docs/source-date-epoch/ ) should be increased
every time the build output changes. Rebuilds with different build dependencies
do not necessarily have a new changelog entry. To ensure that it increases
increment the `SOURCE_DATE_EPOCH` by
For reproducible builds in OpenSUSE the `BUILDHOST` is set to the string
`reproducible` via `%_buildhost`. The tag is not needed to get its benefit as
there is an alternative way: make sure the build host is printed in the build
logs (logs do not need to be reproducible), archive the logs of all
34 matches
Mail list logo
