securedrop-ossec-{client, server} not upgrading via cron-apt due to dependencies not being in security channel

[emkll]

Description

Changes introduced in the packaging logic of #5196 require two new dependencies for these packages to support ossec 3.6.0 and new pcre-based matching . This was not caught during review, and can only be reproduced in production scenarios: upgrade testing does a full apt-upgrade and does not use cron-apt (see #4659 (comment))

Steps to Reproduce

• Install 1.2.0
• Update to 1.3.0-rc1
• Observe securedrop-ossec-client and securedrop-ossec server held back due to dependencies not existing in the security channel

Expected Behavior

securedrop-ossec-client and securedrop-ossec-server packages should be updated

Actual Behavior

The securedrop-ossec-client and securedrop-ossec-server packages are held back

Comments

• For libevent, we can consider/ try using https://packages.ubuntu.com/xenial/libevent-2.0-5 instead of the version specified
• For libpcre, I can't find a library in xenial that is also in the security list

[zenmonkeykstop]

IIRC, OSSEC needs v1 of libevent, so the version mentioned above may not work.

For libpcre2, there is always the option to compile it in from a source tarball - this was rejected during initial investigation as it introduces another dependency to track, but it might be worth revisiting that.

[emkll]

Another option is to mirror the packages on apt.freedom.press, the added burden of tracking of dependency/upgrades remain.

The underlying issue is tracked in #3376

[redshiftzero]

Another option related to apt.freedom.press hosting of dependencies: we could only host these two dependencies for the duration of the 1.2.2 -> 1.3.0 upgrade, that reduces the maintenance burden of tracking dependency/upgrades for those two packages, since future fresh installs on 1.3.0 will install from upstream's repo after we remove them from FPF's repo when all instances have updated.

[zenmonkeykstop]

@redshiftzero is there precedent for doing that with other packages? I worry that we'd have to maintain them indefinitely as there could conceivably be unknown instances on an older SD version that don't update for a while.

[redshiftzero]

Nope, to my knowledge we've never done that before, this was just an idea to reduce maintenance burden on our side since we strictly only need the packages during the upgrade window. Regarding indefinitely hosting these packages, we could do something like host them for the duration of the 1.3.x series, and we announce with the release notes in 1.3.0 that once 1.4.0 is released (we can share the planned release date), the automated server upgrade path from 1.2.x to 1.3.0 will no longer be supported. For the period of time where we have the dependencies on our apt server we will need to monitor for updates, but with the release of 1.4.0, we remove them.

It seems like otherwise the options that haven't been mentioned are: upgrade only to a version of OSSEC that doesn't require libpcre2 which looks like it's quite a while back (OSSEC 3.2.0), modify the cron-apt logic (#3376, but I think we'd need to do that in one release and then issue another release with the OSSEC change), or back this OSSEC update out entirely for now.

What do you think @zenmonkeykstop @emkll ? To me hosting the packages for a restricted period of time is probably the best option, but thoughts welcome.

[zenmonkeykstop]

As per OOB suggestion by @eloquence, 1.4.0 seems a little too soon but going as far as 1.5.0 makes sense, with the proviso that we would have to look out for security-focused releases of the packages in question and update our mirror. Otherwise yup, this is the best option given the situation.

Adding them on the apt-test repo at least should just be a PR into the securedrop-dev-packages-lfs repo - @emkll is there any verification process that you'd like to see for the packages beforehand?

[emkll]

@redshiftzero @zenmonkeykstop I think this approach makes sense (given the significant complexity of #3376). If we retrieve them through apt download (which verifies the integrity of the deb through the release file), it would be similar to what we do with the tor packages.

Regarding the updates to packages, since we don't set priority to apt sources, at install time, if a higher version of the package exists on Ubuntu's apt servers, those will be downloaded. If a package is updated in the security channel, that version will be upgraded on all servers.

• libevent is Canonical maintained, therefore should receive security updates in the security no matter what
• libpcre2 is part of the universe channel, therefore community maintained, and patches can still be provided to the security repo [1]. It is unclear what the maintainers policy is here and there doesn't seem to be any drop-in replacements

[1] : https://wiki.ubuntu.com/SecurityTeam/UpdateProcedures#Preparing_an_update

[emkll]

Packages have been added to the dev repo in freedomofpress/securedrop-apt-test#40

Packages are now live on apt-test:

• https://apt-test.freedom.press/pool/main/libe/libevent1/
• https://apt-test.freedom.press/pool/main/p/pcre2/

Added a note to the checklist in #5205 to remind us to port these packages to the prod repo on release day

[zenmonkeykstop]

I'm doing a cron-apt upgrade against NUCs today, will verify that this is working as expected as part of that.

[zenmonkeykstop]

OSSEC upgrading OK across tested hardware, yay!

One thing re @emkll's comment above. libevent2 is Canonical-maintained, but OSSEC relies on libevent1, which is in universe. So we'd be in the same boat re: tracking updates for both packages.

[eloquence]

This was resolved as part of the SecureDrop 1.3.0 release. Should we open a follow-up task to monitor for updates & remove mirrored dependencies with 1.5.0, and then close this one?

[eloquence]

Follow-up ticket #5312 opened, closing this one.