Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request] Provide API to access a solvable's update candidate #474

Open
JonathanKang opened this issue Jul 31, 2023 · 4 comments
Open
Labels

Comments

@JonathanKang
Copy link

A new API to get a package's update candidate and its related information(especially release note) will be helpful to implement get-update-detail method in PackageKit's zypp backend to fix this bug.

@mlandres
Copy link
Member

mlandres commented Aug 1, 2023

@JonathanKang I don't know how this should work. Our domain are (rpm)packages. Whatever appdata.xml describes does not map well to our packages and the primary.xml we refer to. And most repos seem to provide no appdata.xml at all. That's why we don't consume them.

Take for example gnome-shell-extension-gpaste in our current 15.4 repo-oss:

S | Name                         | Type    | Version            | Arch   | Repository
--+------------------------------+---------+--------------------+--------+-----------
  | gnome-shell-extension-gpaste | package | 3.42.2-bp154.1.169 | noarch | repo-oss

And the only occurrence of it in the repos appdata.xml:

  <component type="shell-extension">
    <id>GPaste_gnome-shell-extensions.gnome.org</id>
    <pkgname>gnome-shell-extension-gpaste</pkgname>
    <source_pkgname>gpaste</source_pkgname>
    <translation type="gettext">GPaste</translation>
    <name>GPaste</name>
    <summary>GNOME Shell Extension</summary>
    <description><p>Clipboard management system</p></description>
    <kudos>
      <kudo>ModernToolkit</kudo>
      <kudo>SearchProvider</kudo>
    </kudos>
    <project_license>BSD-2-Clause</project_license>
    <url type="homepage">http://github.com/Keruspe/GPaste</url>
    <releases>
      <release version="41.0"/>
    </releases>
    <provides>
      <dbus type="session">org.gnome.GPaste</dbus>
      <dbus type="session">org.gnome.GPaste.Ui</dbus>
    </provides>
    <languages>
      <lang percentage="58">de</lang>
      <lang percentage="66">es</lang>
      <lang percentage="99">fr</lang>
      <lang percentage="83">it</lang>
      <lang percentage="52">ja</lang>
      <lang percentage="57">nb_NO</lang>
      <lang percentage="95">pl</lang>
      <lang percentage="100">pt_BR</lang>
      <lang percentage="77">sv</lang>
      <lang percentage="100">tr</lang>
      <lang percentage="93">zh_CN</lang>
    </languages>
    <metadata>
      <value key="shell-extensions::uuid">[email protected]</value>
    </metadata>
  </component>

Apart from the name they seem to have not much in common. And many packages do not even occur in appdata.xml.

A Solvable's update candidate is found by PoolItem pi = ui::Selectable::get( solvable )->updateCandidateObj().

@JonathanKang
Copy link
Author

Okay. I thought libsolv would provide such data, but it turns out that it doesn't.

With my testing with Fedora and Ubuntu, they both are able to generate such data and feed it to PackageKit. So I wonder whether we openSUSE can do the same.

Ubuntu has a class named pkgAcquire to download related data and then parse release note from it. For Fedora, xxxxxx-updateinfo.xml exists in each repository's repodata directory. These files contain release notes for the updates available. DnfAdvisory exists to serve such a purpose.

Maybe we can implement something similar? For instance, use changelogs from .changes file in each package to provide such data. These are maintained by package maintainers and they represent what's changed from previous version very well.

@mlandres
Copy link
Member

mlandres commented Aug 3, 2023

Regarding updateinfo.xml, it's the metadata file defining patches. The corresponding PoolItems/Solvables are those of kind ResKind::patch. The patch's description usually lists the defects the patch fixes:

# zypper info patch:openSUSE-SLE-15.4-2023-3162

Information for patch openSUSE-SLE-15.4-2023-3162:
--------------------------------------------------
Repository  : repo-sle-update
Name        : openSUSE-SLE-15.4-2023-3162
Version     : 1
Arch        : noarch
Vendor      : [email protected]
Status      : needed
Category    : security
Severity    : important
Created On  : Wed 02 Aug 2023 12:42:34 PM CEST
Interactive : ---
Summary     : Security update for MozillaFirefox
Description : 
    This update for MozillaFirefox fixes the following security issues:

      Firefox was updated to Extended Support Release 115.1.0 ESR (bsc#1213746):

      - CVE-2023-4045: Fixed cross-origin restrictions bypass with Offscreen Canvas (bmo#1833876).
      - CVE-2023-4046: Fixed incorrect value used during WASM compilation (bmo#1837686).
      - CVE-2023-4047: Fixed potential permissions request bypass via clickjacking (bmo#1839073).
      - CVE-2023-4048: Fixed crash in DOMParser due to out-of-memory conditions (bmo#1841368).
      - CVE-2023-4049: Fixed potential race conditions when releasing platform objects (bmo#1842658).
      - CVE-2023-4050: Fixed stack buffer overflow in StorageManager (bmo#1843038).
      - CVE-2023-4052: Fixed file deletion and privilege escalation through Firefox uninstaller (bmo#1824420).
      - CVE-2023-4054: Fixed lack of warning when opening appref-ms files (bmo#1840777).
      - CVE-2023-4055: Fixed cookie jar overflow caused unexpected cookie jar state (bmo#1782561).
      - CVE-2023-4056: Fixed memory safety bugs (bmo#1820587, bmo#1824634, bmo#1839235, bmo#1842325, bmo#1843847).
      - CVE-2023-4057: Fixed memory safety bugs (bmo#1841682).

      Bugfixes:

      - Remove bashisms from startup-script (bsc#1213657)
Provides    : patch:openSUSE-SLE-15.4-2023-3162 = 1
Conflicts   : [22]
    srcpackage:MozillaFirefox < 115.1.0-150200.152.99.1
    MozillaFirefox.noarch < 115.1.0-150200.152.99.1
    MozillaFirefox.x86_64 < 115.1.0-150200.152.99.1
    MozillaFirefox-branding-upstream.x86_64 < 115.1.0-150200.152.99.1
    MozillaFirefox-branding-upstream.noarch < 115.1.0-150200.152.99.1
    MozillaFirefox-devel < 115.1.0-150200.152.99.1
    MozillaFirefox-translations-common.x86_64 < 115.1.0-150200.152.99.1
    MozillaFirefox-translations-common.noarch < 115.1.0-150200.152.99.1
    MozillaFirefox-translations-other.x86_64 < 115.1.0-150200.152.99.1
    MozillaFirefox-translations-other.noarch < 115.1.0-150200.152.99.1
    MozillaFirefox.s390x < 115.1.0-150200.152.99.1
    MozillaFirefox-branding-upstream.s390x < 115.1.0-150200.152.99.1
    MozillaFirefox-translations-common.s390x < 115.1.0-150200.152.99.1
    MozillaFirefox-translations-other.s390x < 115.1.0-150200.152.99.1
    MozillaFirefox.ppc64le < 115.1.0-150200.152.99.1
    MozillaFirefox-branding-upstream.ppc64le < 115.1.0-150200.152.99.1
    MozillaFirefox-translations-common.ppc64le < 115.1.0-150200.152.99.1
    MozillaFirefox-translations-other.ppc64le < 115.1.0-150200.152.99.1
    MozillaFirefox.aarch64 < 115.1.0-150200.152.99.1
    MozillaFirefox-branding-upstream.aarch64 < 115.1.0-150200.152.99.1
    MozillaFirefox-translations-common.aarch64 < 115.1.0-150200.152.99.1
    MozillaFirefox-translations-other.aarch64 < 115.1.0-150200.152.99.1

A zypp::Patch however is associated with a bunch of packages. You can't tell exactly which defect applies to which (subset of) packages.

As you can see, Patches do not require a specific version of a package, but they conflict with the vulnerable versions. The versions in the conflicts are the least package versions fixing the issue. The Patch::contents method collects those least-versions and returns them in a SolvableSet.

In case maintenance also provides a detailed list of issue references for the patch (CVE or bugzilla IDs e.g) the Patch::ReferenceIterator will provide them.

@mlandres
Copy link
Member

mlandres commented Aug 3, 2023

Regarding changelogs from .changes file in each package. Well, those data are provided by the repository in the other.xml.

Leap-15.4 repo-oss:
  11K  repomd.xml
  481  repomd.xml.asc
  988  repomd.xml.key
 3.3K  license.tar.gz
 486K  susedata.de.xml.gz
 3.9M  appdata-icons.tar.gz
 4.8M  appdata.xml.gz
 6.2M  susedata.xml.gz
  26M  primary.xml.gz
  31M  other.xml.gz
  62M  filelists.xml.gz

Due to their (download)size and the (time)penalty when caching and loading them into the libsolv pool, we don't download other.xml and filelists.xml. That's why the Package::changelog is available for installed packages only.

AFAIK there is a zypper-changelog-plugin availble (at least on TW). A similar on-demand solution built-in libzypp is desirable, but ATM missing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants