Mailinglist Archive: opensuse-features (291 mails)

< Previous Next >
[openFATE 305503] zypper: allow update by issues/bugs/advisories
  • From: fate_noreply@xxxxxxx
  • Date: Fri, 21 May 2010 12:51:57 +0200 (CEST)
  • Message-id: <feature-305503-40@xxxxxxxxxxxxxx>
Feature changed by: Ján Kupec (jkupec)
Feature #305503, revision 40
Title: zypper: allow update by issues/bugs/advisories

openSUSE-11.2: Done
Requester: Desirable
Projectmanager: Mandatory

Requested by: Duncan Mac-Vicar (dmacvicar)
Developer: (Novell)
Developer: (Novell)
Partner organization:

YUM security plugin allows to filter updates showing only ones that
mention certain issues. Example:
yum update --security
yum update --bz 410101
yum update --cve CVE-2007-5707 --advisory RHSA-2007:1082-5
As our patches contains this metadata, we could add similar
functionality to zypper.
The scope is only for zypper. Other front ends would require some GUI
concept first.
Open Issues:
libzypp's PoolQuery would need support for subattributes (updateinfo.
xml references are stored as subarrays)
User experience
* Adds command line options like the ones described above.
* libzypp
Contingency Plan
* Feature is new, so in a bad scenario it can simple be deactivated.

- updateinfo XML scheme (url:;a=blob_plain;f=zypp/parser/yum/schema/updateinfo.rnc;hb=HEAD)
- Tips and tricks: yum-security (url:

Documentation Impact:
New command line options would need to be documented.

Test Case:
The testing of this feature can be done creating a repository (for
example using enhancerepo) containing patches that reference issues,
like described in , and
then performing updates passing to zypper command line the issues,
confirming that only those issues are shown.

Use Case:
Sysadmin is only interested in particular updates to solve security
issues or specific bug numbers or advisories.

Business case (Partner benefit): Sysadmins do not update ther systems without a strict
process and maximum care. Therefore it is very important to allow them
to update the system to fix a single issue. It would save them the time
to look that themselves package per package.

#1: Marcus Meissner (msmeissn) (2008-12-03 14:51:14)
Random notes:
- CVE-XXXX-YYYY RPM provides after fixing issues?
- OVAL relation?

#2: Duncan Mac-Vicar (dmacvicar) (2008-12-03 16:02:46) (reply to #1)
About CVE provides.
Right now the CVE information is in the patch (since 11.0). I don't
have anything against having it as Fix(CVE-XXX-XXX) provides, but I am
not sure if having them in both makes sense. Specially in the case that
one issue needs more than one package, you will need to install all
packages fixing the issue, and if you have 2 repos with 2 same packages
providing the issue, they will conflict.

#3: Duncan Mac-Vicar (dmacvicar) (2008-12-03 16:08:13) (reply to #1)
I don't have knowledge how OVAL works, may be you can provide some very
concrete example scenarios for the feature described above.
What I can say is that the reason why the repository/product
compatibility and update information in SLE11/openSUSE 11.1 is
supported using CPE ( that is, product can contain a CPE id, and repos
can tell to which CPE they are compatible and which CPE they update
with fixes ) was to enhance our ability to do semantic queries like
relate upstream security issues and installed products. OVAL uses CPE
as the platform descriptor AFAIK.

#4: Dirk Mueller (dirkmueller) (2008-12-04 14:58:01)
adding rpm provides was also my first idea, but that has a side effect:
often enough, CVE numbers are not yet known when the package is built
and ends up in QA, and editing rpm provides essentially needs a
rebuild, which invalidates QA.
so preferably we need a way to update the rpm provides without doing a
rebuild (bad) or we need a way to add it to the meta information (which
is currently generated via patchinfo and where it is also too late).
an idealistic approach would be to make sure that we can update this
meta information after patchinfo checkin (entering the data into swamp
and autobuild fetches that information when the update is released and
adds it to the meta info).

#5: Federico Lucifredi (flucifredi) (2009-01-07 15:52:34)
This has quite a bit of customer value.
BTW, there may be a duplicate out there

#6: Michael Andres (mlandres) (2009-07-01 18:33:01)
libzypp-6.9.2 supports PoolQuery of subattributes. So one can e.g
search for patches with updateReferenceId "CVE-2007-5707', or of
updateReferenceType 'bugzilla",... (I'll provide some sample code)
@Jano: I'll provide some code example, that tells how to access and
iterate the matching updateReferences. So you could start working on

#7: Ján Kupec (jkupec) (2009-07-03 15:10:56)
Thanx! I have a question about the reference types. What types do we
support? in updateinfo.rnc (see references) i only see bugzilla and
Do we want separate options for all supported types, like yum has?

#9: Ján Kupec (jkupec) (2009-07-03 15:57:19) (reply to #7)
Also, i noticed in 11.1 updates repository, that many bugs have a CVE,
but it's only in the description, not in the 'reference' metadata. Only
bugzilla is in 'reference'. Do we want to address this?

#10: Marcus Meissner (msmeissn) (2009-07-03 15:59:21) (reply to #9)
we are not emitting it yet. this also needs to be done :/

#8: Ján Kupec (jkupec) (2009-07-03 15:20:18)
Suggestion how the commands could look like:
$ zypper fix --search [string]
$ zypper fix --bugzilla <#>
$ zypper fix --cve <#>

#11: Klaus Kämpf (kwk) (2009-07-04 12:11:44) (reply to #8)
Please re-think about introducing another term ( fix ), we already have
* update
* upgrade
* patch

#12: Ján Kupec (jkupec) (2009-07-07 10:11:04) (reply to #11)
What i try to achieve is to have a way to install the patches fixing
the issues and a way to list them (issue number & patch name & (patch)
description), search in them. The other alternatives i considered were:
$ zypper patch [--bugzilla #] [--cve #]
$ zypper list-patches --issues [string]

The first command looks nice, but i don't know what to use to
list/search the issues - the list-patches command does not seem right
to me - looks more like it deserved a new command.
$ zypper install [--bugzilla #] [--cve #]
$ zypper search --issues [string]

In this case, like in the 'list-patches --issues' case, the search
command would either need to radically change its output, or user would
need to call 'zypper patch-info the_found_patch' to get the patch
Any other ideas? Why is having a new command a bad thing (esp. compared
to having new options in the existing commands)?
BTW: (We don't have 'upgrade' :O)

#13: Martin Vidner (mvidner) (2009-07-07 14:33:03) (reply to #12)
Why reinvent the wheel? Can we just copy yum's interface as described
in the referenced yum-security article?

#14: Ján Kupec (jkupec) (2009-07-07 14:57:27) (reply to #13)
'zypper update' does not work with patches. 'zypper patch' looks to me
like better candidate for new --bz or --cve options. yum does not make
difference between these two. The yum plugin also adds a new command
(list-sec), which was Klaus' objection.

#15: Klaus Kämpf (kwk) (2009-07-07 15:51:26) (reply to #14)
Well, my objection is the new term 'fix' besides 'update' and 'patch'
and will confuse people.
It should be an option to "list" or "list-patches" imho

#16: Ján Kupec (jkupec) (2009-07-07 16:16:12) (reply to #15)
OK, so far the following looks like a candidate (taken yum into account
as well):
# to install a fix
$ zypper patch [--bz #] [--cve #] [--any-other #]
# to list available needed fixes (issue-number, patchname-version,
category, description)
# all
$ zypper list-patches --issues
# matching a substring ("CVE", number, or any)
$ zypper list-patches --issues foo
# only CVEs/bugzillas
$ zypper list-patches [--cve] [--bz]

#17: Ján Kupec (jkupec) (2009-07-15 09:24:34)
Done in zypper. You can fetch zypper 1.2.2 from home:jkupec:Factory to
try and let me know what you think. New options in lp and patch
$ zypper help lp
-b, --bugzilla[=#] List needed patches for Bugzilla issues.
--cve[=#] List needed patches for CVE issues.
--issues[=string] Look for issues matching the specified
-a, --all List all patches, not only the needed ones.
$ zypper help patch
patch [options]
-b, --bugzilla # Install patch fixing the specified bugzilla
--cve # Install patch fixing the specified CVE issue.

--bz works, too.
Can this feature be closed, or we'll close it after the repo metadata
have the CVE references?

#25: brodie brodie (brodie31k) (2010-04-16 20:11:58) (reply to #17)
The listing packages by issues is great, but why is there no
coredsponding --issue option for the for zypper update?
Does not seem to make sense that you can list packages by issue, but
not then update then by issue.

+ #26: Ján Kupec (jkupec) (2010-05-21 12:51:47) (reply to #25)
+ Look at c#17 more closely: it's 'list-patches' to list them and 'patch'
+ to install them. 'list-updates' and 'update' is a different approach to
+ updating. You can find more info in zypper's man page and wiki.

#18: Ján Kupec (jkupec) (2009-07-15 09:30:38)
One more thing that crossed my mind when looking at the yum article
They seem to be able to associate issue numbers with spcecific
packages. I'm not sure if this is because they just avoid issuing
updates with plenty of packages in single <update> tags, like we often

#19: Christoph Thiel (cthiel1) (2009-07-16 11:33:39) (reply to #18)
Rudi, is autobuild planning to adding additional information to the

#20: Ruediger Oertel (oertel) (2009-08-26 12:12:41) (reply to #19)
Not as the driving element. But we usually implement these extensions
when maintenance and zypp development request them.

#21: Ján Kupec (jkupec) (2009-09-21 10:58:06) (reply to #20)
Well, we would like CVEs in the patches :O) So i repeat my question:
Can this feature be closed, or we'll close it after the repo metadata
have the CVE references?

#22: Ruediger Oertel (oertel) (2009-11-18 16:27:31)
I just need the URL to enter as CVE reference to complete my side.

#23: Ruediger Oertel (oertel) (2009-11-18 17:19:01) (reply to #22)
got the url from dirk in bnc#556293. my side is implemented now.

#24: Ján Kupec (jkupec) (2009-11-19 12:58:35) (reply to #23)
So we have it in zypper, we have it in metadata. Done.

openSUSE Feature:

< Previous Next >
This Thread
  • No further messages