July 2009 - openSUSE Features - openSUSE Mailing Lists

[openFATE 305503] zypper: allow update by issues/bugs/advisories
by fate_noreply＠suse.de 01 Jul '09

01 Jul '09

Feature changed by: Michael Andres (mlandres) Feature #305503, revision 13 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: - 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. -- openSUSE Feature: https://features.opensuse.org/305503

1 0

[openFATE 306605] openSUSE Server Edition
by fate_noreply＠suse.de 01 Jul '09

01 Jul '09

Feature added by: Joe Brockmeier (jbrockmeier) Feature #306605, revision 1 Title: openSUSE Server Edition Requested by: Joe Brockmeier (jbrockmeier) Description: Define and create an openSUSE "Server Edition" that contains the necessary packages for a home / LAMP server. -- openSUSE Feature: https://features.opensuse.org/306605

1 5

[openFATE 305547] Support for ECDSA in yast2 ca_mgm
by fate_noreply＠suse.de 01 Jul '09

01 Jul '09

Feature changed by: Vit Pelcak (vpelcak) Feature #305547, revision 7 Title: Support for ECDSA in yast2 ca_mgm openSUSE-11.2: New Priority Requester: Mandatory Requested by: Vit Pelcak (vpelcak) Description: It would be good if yast2 ca_mgm supported ECDSA keys. This feature is necessary to support RFC 4869. Currently only RSA is supported. Discussion: #1: Andreas Jaeger (a_jaeger) (2009-06-09 14:22:26) What is the advantage here? From the description I'm not seeing any benefit of implementing this. + #2: Vit Pelcak (vpelcak) (2009-07-01 08:24:04) (reply to #1) + This feature request came out from discussion with Marius Tomaschewski + when I was testing one feature about ipsec, IKEv2 and ECDSA in RFC + 4869. + We came to conclusion that it would be good if it would be implemented + in Yast2. -- openSUSE Feature: https://features.opensuse.org/305547

1 0