Mailinglist Archive: opensuse-features (829 mails)

< Previous Next >
[openFATE 305503] zypper: allow update by issues/bugs/advisories
  • From: fate_noreply@xxxxxxx
  • Date: Sat, 4 Jul 2009 12:12:04 +0200 (CEST)
  • Message-id: <feature-305503-18@xxxxxxxxxxxxxx>
Feature changed by: Klaus Kämpf (kwk)
Feature #305503, revision 18
Title: zypper: allow update by issues/bugs/advisories

openSUSE-11.2: Candidate
Priority
Requester: Desirable
Projectmanager: Mandatory

Requested by: Duncan Mac-Vicar (dmacvicar)
Partner organization: openSUSE.org

Description:
Description:
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.
Scope
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.
Dependencies
* libzypp
Contingency Plan
* Feature is new, so in a bad scenario it can simple be deactivated.

Relations:
- updateinfo XML scheme (url:
http://git.opensuse.org/?p=projects/zypp/libzypp.git;a=blob_plain;f=zypp/parser/yum/schema/updateinfo.rnc;hb=HEAD)
- Tips and tricks: yum-security (url:
http://www.redhatmagazine.com/2008/01/16/tips-and-tricks-yum-security/)

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

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

Business case (Partner benefit):
openSUSE.org: 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.

Discussion:
#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
zypper.

#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
cve
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




--
openSUSE Feature:
https://features.opensuse.org/305503

< Previous Next >
This Thread
References