Note that we need to come up with something that works both for `Source:` and
`%sourcelist`
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/463#issuecomment-1991682334
You are receiving this because you are subscribed to this thread.
> > This is an orthogonal discussion. you can have multiple variants in both
> > suggestions of mine (also in the fragmet suffix)
>
> Maybe you din't notice but I've proposed not one but two variants. Main point
> which I've added is to use pk11 like csum format. From that point of view
>
What about having macros such as:
~~~
Source: %checksum(ULR, sha256, )
~~~
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/463#issuecomment-1635727081
You are receiving this because you are subscribed to this thread.
Message ID:
> This is an orthogonal discussion. you can have multiple variants in both
> suggestions of mine (also in the fragmet suffix)
Maybe you din't notice but I've proposed not one but two variants.
Main point which I've added is to use pk11 like csum format. From that point of
view everything from
@kloczek I am fully aware of the autonumbering functionality for
sources/patches, but SourceCSum is not backward compatible with older rpm
versions, so you would have to do something like
```spec
%if %{with somecondition}
Source: file1
%if %rpm_is_new_enough
SourceCSum: sha256(checksum)
%endif
> I think that makes it really tricky with ordering (is it applying to the next
> source or the previous one? and what if there are conditionals around source
> lines?). imho really not very intuitive as it is very context dependent.
Currentpy you can use:
```spec
Source: file1
Source: file2
.
> I would like to see something more like pk11 format
>
> ```python
> SourceCSum: sha256://
```
I think that makes it really tricky with ordering (is it applying to the next
source or the previous one? and what if there are conditionals around source
lines?). imho really not very intuitive as
> > Unfortunately the suggested format of `Source(sha256): format` is not
> > backward compatible with older rpm releases, and having the checksum as an
> > extra tag (with autonumbering) and if conditions could be error prone and
> > tricky.
> Is backward compatibility really an issue if we're
I would like to see something more like pk11 format
```spec
SourceCSum: sha256://
```
Which would allow use different checksums algorithms.
Or as second argument of the `Source:`
```spec
Source: sha256://
```
--
Reply to this email directly or view it on GitHub:
> Unfortunately the suggested format of `Source(sha256): format` is not
> backward compatible with older rpm releases, and having the checksum as an
> extra tag (with autonumbering) and if conditions could be error prone and
> tricky.
Is backward compatibility really an issue if we're talking
Unfortunately the suggested format of `Source(sha256): format` is not backward
compatible with older rpm releases, and having the checksum as an extra tag
(with autonumbering) and if conditions could be error prone and tricky. so
@mlschroe came up with an alternative proposal:
```
Source
It would be useful. When an [OpenPGP upstream
signature](https://docs.fedoraproject.org/en-US/packaging-guidelines/#_source_file_verification)
is not available and one wants to have the checksum verification, it needs to
be performed manually in the `%prep` section (similarly to the things
I think so, yes.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/463#issuecomment-1474507843
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint
> It should be compatible with that too, since it's effectively
> `Tag(qualifier)` format.
But how you match them? By order?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/463#issuecomment-1474497024
You are receiving this because
It should be compatible with that too, since it's effectively `Tag(qualifier)`
format.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/463#issuecomment-1474183736
You are receiving this because you are subscribed to this thread.
> ```
>
> Source0: https://host/path/to/tarball.tar.gz
> Source0(sha512):
> Source0(sha1):
> ```
I might be wrong, but I thought that `Source` without any number is the
modern/future/preferred way of specifying sources. Therefore I am not sure how
`Source(sha512)` would play together
I like that and would love to see an implementation for it.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/463#issuecomment-1474042087
You are receiving this because you are subscribed to this thread.
Message ID:
I like the idea and I came up with a similar syntax some time ago (just in my
head):
```
Source0: https://host/path/to/tarball.tar.gz
Source0(sha512):
Source0(sha1):
```
if any of those are set, rpm should (always, optionally?) check the checksum
before starting with %prep.
@dmnks @ffesti @pmatilai Could you consider adding this to your backlog(s)?
There seem to be a demand for this feature in multiple distros (see all the
comments above).
--
Reply to this email directly or view it on GitHub:
OKAY. so rpmlint should check three checksums match:
1. downloaded file from github
2. attached archive in srpm
3. sha-256 sum in .spec file
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> Github is trusted because of in git (i.e. block-chain) it's impossible to
> have different content under the same hash-tag.
That's not actually true. Git uses SHA1 and collisions have been done to Git
with it. That also said, GitHub archives may or may not be reproducible. And
Git refs are
I want rpmlint to fight against packagers who unintentionally put wrong
archives. Yes, I trust github, so I want rpmlint to download from github, i.e.
1. unpack .srpm
2. remove archives that are expected to be from github
3. run something like `rpmbuild --undefine=_disable_source_fetch --define
Yes, that's what I meant. Some implicit hook in %prep implementation, or
before.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Implementing it that way would require making changes to `%prep` initialization
in RPM, so that it would run before anything is executed...
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Lemme know if you think that some PoC macro in /usr/lib/rpm/macros.d doing
exactly
this would be useful (as first %prep instruction).
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Could RPM hook in a check right before executing `%prep` section if e.g. macro
like
`%global source_1_sha256 ` is defined? Older RPM implementations
would
just ignore such macro.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
Unfortunately, the minimalistic solution is used for something else already:
URL fragments are used to have a different file name from what a download from
the URL would normally yield, e.g. if an on-the-fly generated upstream archive
doesn't contain the package name.
--
You are receiving
Well, on the other hand, it is a minimalistic solution that doesn't introduce
any new rpm constructs. Also, you don't need to know or read the RFC. You just
need to read the rpm documentation where it is described that source checksums
are attached to source URLs as `#()` suffixes. With an
In reply to
https://github.com/rpm-software-management/rpm/issues/463#issuecomment-601922444:
```
Source0:
https://github.com/release-engineering/dist-git/archive/dist-git-1.12-1.tar.gz#sha256
```
> with the current rpm syntax and then have a macro that verifies the tarball
> checksum based on
But, yeah, maybe you guys have some other/better solution in mind. Idk.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Cool, ok, I admit I am not sure how big deal is the macOS compatibility. I
think if somebody complains that the feature doesn't work there, it would be a
reason to instead use some c library for the checksum validation. Maybe that
could be done immediately? I would still consider relying on
> Alright but I think we are maybe tracking different goals then :). I thought
> the issue was about making `%_disable_source_fetch 0` reliable. It's what the
> original post suggested to me.
It is about that. We don't want to operate on sources unless they've been
validated to be good. That
> > We could use a bit of bash code `%([ "$(sha256sum
> > | cut -d " " -f 1)" = ])` to do the verification per downloaded
> > source
>
> Yep, something like this is where I was heading to.
>
> > but i think `` might be slightly tricky unless rpm
> > exposes enviroment variable like
> We could use a bit of bash code `%([ "$(sha256sum |
> cut -d " " -f 1)" = ])` to do the verification per downloaded
> source
Yep, something like this is where I was heading to.
> but i think `` might be slightly tricky unless rpm
> exposes enviroment variable like 'SOURCES'
RPM exposes
On macOS, there is not a consistent interface for doing checksums via CLI. I'm
unsure if AIX and other platforms would also have similar problems.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Hmm, on Fedora:
```
$ dnf repoquery --requires rpm
Last metadata expiration check: 0:00:08 ago on Tue 24 Mar 2020 01:34:47 PM CET.
/usr/bin/bash
/usr/bin/db_stat
/usr/bin/sh
coreutils
curl
libarchive.so.13()(64bit)
libc.so.6(GLIBC_2.4)(64bit)
libpopt.so.0()(64bit)
libpopt.so.0(LIBPOPT_0)(64bit)
RPM does not *specifically* require GNU coreutils. And `sha256sum` and friends
are _not_ specifically available on all platforms RPM is used on.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> @voxik That is for verifying GPG signatures if they exist, and yes, it
> requires `gnupg2` as a build dependency in that scenario.
But if that was macro included in RPM, RPM would probably grow the dependency,
so it would not need BR. So I still think this could be way forward.
--
You are
@voxik That is for verifying GPG signatures if they exist, and yes, it requires
`gnupg2` as a build dependency in that scenario.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> I actually wonder, why the check is done in `%prep`.
This might be due to `BR: gnupg2`, have not investigated this.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Thinking further about this, do we actually need something really fancy as
special tag?
For example, it is quite easy to check if the checksums in the dist-git sources
file are correct during `rpmbuild -bs`. It is enough to put `%(sha512sum -c
sources)` somewhere into specfile preamble. If the
Anyway, what about something like `%_verify_fetched_source_checksums` macro
with values `0/1/2` where
```
0: do not check source checksums even if present
1: check source checksums if present as `#()` url suffix by
invoking `sum` command from coreutils to do the check
2: check source checksums
> One problem with the `sources` file is that it is distro specific -- Fedora
> uses `sources`, OpenMandriva uses a similar file (though with slightly
> different syntax) called `.abf.yml`, probably other distributions have yet
> other workarounds.
>
> Another problem is that it's not the spec
One problem with the `sources` file is that it is distro specific -- Fedora
uses `sources`, OpenMandriva uses a similar file (though with slightly
different syntax) called `.abf.yml`, probably other distributions have yet
other workarounds.
Another problem is that it's not the spec file -- I
...Actually the fragment part shouldn't even be sent to the server so that note
should probably be fixed...
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> For me, causal user of OS sometimes building small packages, current way of
> building rpms is very confusing. There are various tools which duplicate
> functionality: rpmbuild, mock, rpkg, fedpkg etc. It's much harder to
> understand than PKGBUILDs on Arch Linux for example. For me having
For me, causal user of OS sometimes building small packages, current way of
building rpms is very confusing. There are various tools which duplicate
functionality: rpmbuild, mock, rpkg, fedpkg etc. It's much harder to understand
than PKGBUILDs on Arch Linux for example. For me having ability to
Currently, fedpkg downloading and uploading functionality is independent of rpm
which brings an advantage that we can use it to upload/download custom binary
stuff for other "package" types (e.g. containers).
So placing the source hashes into spec file itself would limit the
lookaside-cache
> @praiskup I think what @Conan-Kudo meant is (correct me if I'm wrong), that
> if we have the hashes only in `sources` and not in the spec file, a plain
> local `rpmbuild` can't (safely) download missing sources.
This is correct.
--
You are receiving this because you are subscribed to this
@praiskup I think what @Conan-Kudo meant is (correct me if I'm wrong), that if
we have the hashes only in `sources` and not in the spec file, a plain local
`rpmbuild` can't (safely) download missing sources.
--
You are receiving this because you are subscribed to this thread.
Reply to this
> We cannot rely on this file if we want rpm to be able to auto-download
> sources with any degree of confidence.
Why? _Technically_ there shouldn't be a problem.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> but now thinking about this again, what is the problem with the `sources`
> file in dist-git? It already contains checksums.
We cannot rely on this file if we want rpm to be able to auto-download sources
with any degree of confidence.
Per the comment in the macros.in file:
```rpm-spec
#
#
I know I had me own #570 where I already proposed 3 possibilities:
~~~
Source0: ftp://ftp.example.com/pub/foo/%{name}-%{version}.tar.gz
Checksum0: SHA512 =
2c8211ae5f1578502dc9b29babe7d03ec61f500b3c2dd309be2bbd34fd194abba29d95812e7dab4bfacda13e342323921663464bab4cbf4af0a198e8437233f4
Source0:
In Fedora, we're considering having sources auto-fetched and uploaded to the
lookaside cache as part of accepting PRs for package updates, but to make this
straightforward, we'd want this to be in the spec file so that we know we're
downloading what we're supposed to.
Something along the lines
Would be really useful to have (of course should be optional to keep old spec
files working).
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I should point out that there is a very simple solution for copr (and perhaps
other build systems) that do not wish to use the existing digest (and package
signature) mechanisms in SRPMs:
Use git (or other VCS) for the local cache of virgin sources used by rpmbuild.
If the local cache used git
So copr has a facility that does not use SRPMs: you might consider changing the
facility since SRPMs already provide digests (and package signature) including
verification, exactly what you are requesting as an alternative duplicate
implementation using tags in spec files.
See also issue #446
I'm perfectly fine with the rpm5 syntax and probably with most possible
alternatives - as long as they are usable.
The rpm5 description I could find in the changelog mentions:
digest([:]/path) = hex
I verify checksums all the time. The vast majority of open-source upstream also
cares as
See also issue #413 adding arbitrary tags to supply arbitrary metadata syntax
to spec files
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
See also issue #416 adding arbitrary tags to supply arbitrary metadata to spec
files
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Several points:
* Maintaining digests in spec files -- if mandatory -- adds a great deal of
gratuitous cut-n-paste tedium to package building/management for little real
purpose. Does anyone ever vet the contents of a tar ball before putting its
digest into recipe metadata?
* SRPMs in rpm --
In SPEC files there is the Source0/SourceX directive to specify the sources.
Example:
Source0:
http://releases.nixos.org/patchelf/patchelf-%{version}//%{name}-%{version}.tar.bz2
cf. https://github.com/gsauthof/copr-epel/blob/master/patchelf/patchelf.spec#L9
Other software then uses those
62 matches
Mail list logo
