Brave repo primary.xml being zstd compressed breaks yum on clones

[redhatlab42]

Description

For a while now we've been seeing this error from yum: Parsing primary.xml error: Start tag expected, '<' not found

It's because the brave repo is compressed with zstd and that's not working inside yum on all RHEL-like systems (i.e. Amazon Linux). The repo XML can't be opened so the repo is bad and you can't even yum update without disabling the brave repo.

For some reason the (xkcd) 5th standard gz compression wasn't good enough so we needed the 18th standard zstd compression, to save a trivial amount of bytes.

The manual workaround to still get an updated brave is:

Repo:
yum-config-manager --add-repo https://brave-browser-rpm-release.s3.brave.com/brave-browser.repo

Extract:
yum install zstd
cd /var/cache/yum/x86_64/2/brave-browser/
zstd -d *xml.zst
less *primary.xml

Search up from bottom for 'browser'
Look up for 'location' tag
Get the most recent RPM name
Add rpm to https://brave-browser-rpm-release.s3.brave.com/x86_64/

Direct URL:
wget https://brave-browser-rpm-release.s3.brave.com/x86_64/brave-browser-1.67.123-1.x86_64.rpm

Install:
yum install brave-browser-1.67.123-1.x86_64.rpm

Cleanup to disable the repo:
rm /etc/yum.repos.d/brave-browser.repo

Posted for the searches, the ticket can be closed.

Steps to reproduce

yum-config-manager --add-repo https://brave-browser-rpm-release.s3.brave.com/brave-browser.repo yum update

Actual result

One of the configured repositories failed (Unknown), and yum doesn't have enough cached data to continue. At this point the only safe thing yum can do is fail.

Parsing primary.xml error: Start tag expected, '<' not found

Expected result

Repo updated and parsed

Reproduces how often

Easily reproduced

Brave version (brave://version info)

Current

Channel information

• [X] release (stable)
• [ ] beta
• [ ] nightly

Reproducibility

• [ ] with Brave Shields disabled
• [ ] with Brave Rewards disabled
• [ ] in the latest version of Chrome

Miscellaneous information

No response

[bsclifton]

cc: @mihaiplesa @wknapik

[mihaiplesa]

cc @mschfh @oajara

[mihaiplesa]

yum is deprecated, please use https://brave.com/linux for installing.

[redhatlab42]

That's not helpful, yum is the only package manager on these hosts. That URL says to use dnf but that isn't available to be installed.

The net result is this bug continues and we need to manually extract the XML and then get rid of the brave repo as it ships broken.

# which dnf
dnf: Command not found.

[wknapik]

@redhatlab42 what os/version are you running?

[redhatlab42]

Amazon Linux 2 on that fleet of Workspaces. The extra EPEL stuff is locked down/filtered.

[oajara]

@redhatlab42 I've changed the compression back to gz. I'll leave this issue open until you can confirm after our next version release.

[redhatlab42]

Copy, waiting for the next release. The current fresh pull is v1.67.134 from two days ago. Thanks for tweaking it.

[redhatlab42]

Almost there, (the gzip change worked!) but there's a syntax problem introduced now:

Let's flush the old configs and start fresh:

# yum-config-manager --add-repo https://brave-browser-rpm-release.s3.brave.com/brave-browser.repo
Loaded plugins: amzn_workspaces_filter_updates, priorities, update-motd
adding repo from: https://brave-browser-rpm-release.s3.brave.com/brave-browser.repo
grabbing file https://brave-browser-rpm-release.s3.brave.com/brave-browser.repo to /etc/yum.repos.d/brave-browser.repo
repo saved to /etc/yum.repos.d/brave-browser.repo

# yum update brave-browser
brave-browser                    | 2.0 kB  00:00:00     
brave-browser/x86_64/primary     |  14 kB  00:00:00     
brave-browser                    83/83

Contents of the repo files, note the top level sqlite file isn't there now, it's in the gen/ dir:

# cd /var/cache/yum/x86_64/2/brave-browser/
# ls -lF
total 20
-rw-r--r-- 1 root root 14554 Jul 25 02:39 deadbeefcoffee-primary.xml.gz
-rw-r--r-- 1 root root     0 Jul 26 14:26 cachecookie
drwxr-xr-x 2 root root    51 Jul 26 14:26 gen/
drwxr-xr-x 2 root root     6 Jul 26 14:26 packages/
-rw-r--r-- 1 root root  2019 Jul 25 02:39 repomd.xml

I have now:

# yum check-update brave-browser
brave-browser.x86_64       1.68.128-1      brave-browser

I can re-install, the same version as it's cached:

# yum -y reinstall brave-browser
--> Running transaction check
---> Package brave-browser.x86_64 0:1.67.123-1 will be reinstalled
Running transaction
  Installing : brave-browser-1.67.123-1.x86_64                                                                                     1/1 
  Verifying  : brave-browser-1.67.123-1.x86_64                                                                                     1/1 
Installed:
  brave-browser.x86_64 0:1.67.123-1

I can upgrade another RPM:

# yum -y upgrade ghostscript.x86_64
---> Package ghostscript.x86_64 0:9.54.0-9.amzn2.0.3 will be updated

=======================================================================================================================================
 Package                            Arch                     Version                                Repository                    Size
=======================================================================================================================================
Updating:
 ghostscript                        x86_64                   9.54.0-9.amzn2.0.4                     amzn2-core                   117 k
  Updating   : ghostscript-9.54.0-9.amzn2.0.4.x86_64                                                                               2/8 
  Cleanup    : ghostscript-9.54.0-9.amzn2.0.3.x86_64                                                                               7/8 
  Verifying  : ghostscript-9.54.0-9.amzn2.0.3.x86_64                                                                               6/8 
Updated:
  ghostscript.x86_64 0:9.54.0-9.amzn2.0.4

When I try brave-browser this is the ouput, nothing actually gets done:

# yum -y upgrade brave-browser
Resolving Dependencies
--> Running transaction check
---> Package brave-browser.x86_64 0:1.67.123-1 will be updated
---> Package brave-browser.x86_64 0:1.68.128-1 will be an update

Taking out the vendor's stuff results in:

# yum -y --disableplugin=\* upgrade brave-browser
Error: Invalid version flag: or

Digging deeper in the system site-packages/yum/misc.py we have:

    # now we have 'n, f, v' where f and v could be None and None
    if f is not None and f not in constants.LETTERFLAGS:
        if f not in constants.SYMBOLFLAGS:
            try:
                f = flagToString(int(f))
            except (ValueError,TypeError), e:
                raise Errors.MiscError, 'Invalid version flag: %s' % f
        else:
            f = constants.SYMBOLFLAGS[f]

The definitions of what's supported: https://github.com/rpm-software-management/yum/blob/master/yum/constants.py

site-packages/yum/constants.py:
SYMBOLFLAGS = {'>':'GT', '<':'LT', '=': 'EQ', '==': 'EQ', '>=':'GE', '<=':'LE'}
LETTERFLAGS = {'GT':'>', 'LT':'<', 'EQ':'=', 'GE': '>=', 'LE': '<='}

Updating the output to be more verbose:

raise Errors.MiscError, ':%s:%s:Invalid version flag: %s' % (n, v, f)

gives this:

Error: :(libgtk-3.so.0()(64bit):libgtk-4.so.1()(64bit)):Invalid version flag: or

In the uncompressed hash-primary.xml.gz file is:

# cd /var/cache/yum/x86_64/2/brave-browser/
# gunzip -c *-primary.xml.gz > brave.xml
# grep libgtk brave.xml | grep or
<rpm:entry name="(libgtk-3.so.0()(64bit) or libgtk-4.so.1()(64bit))"/>

So it seems this yum is allergic to the 'or' field in the XML file. If you google around folks are "XML doesn't have logic", but here we are.

The original defs: https://github.com/rpm-software-management/createrepo_c/issues/200#issuecomment-820347399

There's two lines in the current primary.xml with it. As the Brave repo wasn't failing with this a few releases ago, when did the ' or ' get introduced?

<rpm:entry name="(libcurl.so()(64bit) or libcurl-gnutls.so.4()(64bit) or libcurl-nss.so.4()(64bit) or libcurl.so.4()(64bit))"/>
<rpm:entry name="(libgtk-3.so.0()(64bit) or libgtk-4.so.1()(64bit))"/>

So, TL;DR the gzip is fixed and the next problem is the XML itself. Did you want me to make a new Issue or shall we continue with this one?

It looks like you're generating on a Fedora or a recent Redhat host as that is where lots of the observed issues are announced, with the backporting 'this will break' stuff explained. That's great for OS locked packages, but maybe not this sort of generic Linux OS packaged software. It needs to be less bleeding edge. Possibly a locked down earlier OS which just p̶a̶s̶s̶e̶s̶ t̶h̶e̶ b̶u̶t̶t̶e̶r̶ makes packages.

https://fedoraproject.org/wiki/Changes/createrepo_c_1.0.0

[redhatlab42]

afk until mid-Sep.