Home_greyopenFATE - openSUSE feature tracking > #305503
Dashboard | Search | Sign up | Login

Please login or register to be able to edit or vote this feature.

zypper: allow update by issues/bugs/advisories

Feature state




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.

User 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.



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


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

Documentation impact

New command line options would need to be documented.


icons/user_comment.png M. M. wrote: (9 years ago)

Random notes:

- CVE-XXXX-YYYY RPM provides after fixing issues?

- OVAL relation?

icons/user_comment.png D. M. wrote: (9 years ago)

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.

icons/user_comment.png D. M. wrote: (9 years ago)

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.

icons/user_comment.png D. M. wrote: (9 years ago)

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).

icons/user_comment.png F. L. wrote: (9 years ago)

This has quite a bit of customer value.

BTW, there may be a duplicate out there

icons/user_comment.png M. A. wrote: (9 years ago)

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 zypper.

icons/user_comment.png J. K. wrote: (9 years ago)

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?

icons/user_comment.png J. K. wrote: (9 years ago)

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?

icons/user_comment.png M. M. wrote: (9 years ago)

we are not emitting it yet. this also needs to be done :/

icons/user_comment.png J. K. wrote: (9 years ago)

Suggestion how the commands could look like:

$ zypper fix --search [string] 
$ zypper fix --bugzilla <#>
$ zypper fix --cve <#>
icons/user_comment.png K. K. wrote: (9 years ago)

Please re-think about introducing another term (
fix ), we already have

  • update
  • upgrade
  • patch

icons/user_comment.png J. K. wrote: (9 years ago)

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 description.

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)

icons/user_comment.png M. V. wrote: (9 years ago)

Why reinvent the wheel? Can we just copy yum's interface as described in the referenced yum-security article?

icons/user_comment.png J. K. wrote: (9 years ago)

'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.

icons/user_comment.png K. K. wrote: (9 years ago)

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

icons/user_comment.png J. K. wrote: (9 years ago)

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]
icons/user_comment.png J. K. wrote: (9 years ago)

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 commands:

$ 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 string.
-a, --all List all patches, not only the needed ones.
$ zypper help patch
patch [options]
-b, --bugzilla # Install patch fixing the specified bugzilla issue.
--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?

icons/user_comment.png b. b. wrote: (8 years ago)

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.

icons/user_comment.png J. K. wrote: (8 years ago)

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.

icons/user_comment.png J. K. wrote: (9 years ago)

One more thing that crossed my mind when looking at the yum article http://magazine.redhat.com/2008/01/16/tips-and-tricks-yum-security/

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 do?

icons/user_comment.png C. T. wrote: (9 years ago)

Rudi, is autobuild planning to adding additional information to the metadata?

icons/user_comment.png R. O. wrote: (9 years ago)

Not as the driving element. But we usually implement these extensions
when maintenance and zypp development request them.

icons/user_comment.png J. K. wrote: (8 years ago)

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?

icons/user_comment.png R. O. wrote: (8 years ago)

I just need the URL to enter as CVE reference to complete my side.

icons/user_comment.png R. O. wrote: (8 years ago)

got the url from dirk in Bug #556293. my side is implemented now.

icons/user_comment.png J. K. wrote: (8 years ago)

So we have it in zypper, we have it in metadata. Done.

Last change: 8 years ago
Score: 9
  • Negative: 0
  • Neutral: 0
  • Positive: 9
Feature Export
Application-xmlXML   Text-x-logPlaintext   PrinterPrint