Mailinglist Archive: opensuse-factory (443 mails)

< Previous Next >
Re: [opensuse-factory] Re: please someone help with SR#711379


On 02/07/2019 19:57, Takashi Iwai wrote:
On Tue, 02 Jul 2019 12:02:45 +0200,
Simon Lees wrote:



On 02/07/2019 18:12, Takashi Iwai wrote:
On Tue, 02 Jul 2019 10:34:15 +0200,
Richard Brown wrote:

On Tue, 2 Jul 2019 at 08:29, Takashi Iwai <tiwai@xxxxxxx> wrote:

Unfortunately as I stated somewhere else, at the moment in terms of
security / bug fixes this isn't complete enough, there needs to be a
mapping from patch name to bug number in the .changes file and this is
somewhat harder to automate.

Hmm.. how it can be different? This is about *.changes, not about
patchinfo. I don't understand why the automatic tracking of patch
files can be worse.

It really sounds as if you mandate the submission of a hand-written
tax declaration at each time -- even if the whole transactions have
been tracked online -- just because the tax officer prefers reading
the printed papers :)

Simon is talking about the fact that in addition to the patch itself,
the motivation for the patch (such as the CVE#/BOO#/BSC# etc) needs to
be tracked also.
https://en.opensuse.org/openSUSE:Packaging_Patches_guidelines#Patch_markup_.28also_called_.22Tagging_patches.22.29

And as smart as any automated tool could be, I'm pretty sure it's not
going to be able to read the mind of the contributors to know which
bug/security ID was the motivation for adding a patch.

That's a different problem. You must put some bugzilla or CVE
reference to the changelog, yes. That's mandatory.

However, the mapping between the patch file and the bugzilla/CVE
doesn't have to rely on the changelog. Even from the current OBS, you
can deduce the changelog entry revision ID as well as the revision ID
of patch changes. That is, if the changelog entry contains a bug/CVE
reference, this mapping can be obtained automatically from OBS, too.

The problem is some packages may have multiple bug/CVE fixes in one
update, and often these bug numbers won't be referenced in the patch
because commonly the patch is a direct copy or rebase from upstream
and CVE numbers may exist yet or be applicable. Putting CVE's in patch
filenames seems pretty common but isn't everywhere, on the other hand
I don't recall seeing bugzilla numbers in patch names often. So we
could mandate that patch names contain a CVE or bugzilla number where
appropriate but I don't think that is the best solution. Teaching osc
to ask so it knows could work, then it could do the generation, or
packagers could continue listing bug + CVE next to patch names in the
changelog.

But how can you assure this mapping granularity by the changelog? The
bot won't help in this regard, because it checks only whether the
patches are added / deleted in some entries.

Packages are still manually reviewed by human eyes, the bots just save reviewers time by filtering and rejecting requests that clearly don't follow the guidelines.

More I hear, more convinced I am, that the missing piece is about the
meta data handling that should be tied with the file tracking, which
definitely has nothing to do with the rpm changelog itself. We're
relying too much on the abused text entries...

Yeah agreed, although in some distro's RPM changelogs are intended for developers only, so if openSUSE wants to follow this the info is relevant for changelogs, but it would be good if obs knew about it and auto filled it. But the discussion on what changelogs are for was happening in a different subthread so lets leave that there.

--

Simon Lees (Simotek) http://simotek.net

Emergency Update Team keybase.io/simotek
SUSE Linux Adelaide Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx

< Previous Next >