Bug 256877 - security/sequoia: update to 1.16.0
Summary: security/sequoia: update to 1.16.0
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Charlie Li
Depends on:
Reported: 2021-06-28 21:15 UTC by phryk-ports
Modified: 2023-06-09 05:39 UTC (History)
3 users (show)

See Also:
koobs: maintainer-feedback? (phryk-ports)

updates security/sequoia and security/py-sequoia (115.49 KB, patch)
2021-06-28 21:15 UTC, phryk-ports
no flags Details | Diff
security/sq v1 (107.72 KB, patch)
2022-05-27 03:46 UTC, Charlie Li
no flags Details | Diff
security/sq v2 (111.66 KB, patch)
2022-05-28 02:08 UTC, Charlie Li
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description phryk-ports 2021-06-28 21:15:14 UTC
Created attachment 226095 [details]
updates security/sequoia and security/py-sequoia

Sequoia-OpenPGP recently released version `1.3.0`.

Since both sequoia-openpgp (as well as sequoia-sq and sequoia-sqv) and the python bindings live in the same git repo, I'm handing in the updates to both ports in one go. No warnings raised by `portlint` and `make index` runs through without issue.

Some notes:

I added `SONAME`s for the `ffi` and `openpgp-ffi` libs. This isn't possible for `ffi-macros` as it doesn't count as "cdylib". The version supplied in `SONAME` might technically be wrong since they use the `1.3.0` version of the `sequoia-openpgp` crate and not the `0.22.0` of their own crates because this led to issues finding the libs that I couldn't resolve.

Both ports now support the `test` target and the test suites run successfully on the amd64 jail I use for testing purposes – tho for sequoia you first have to install it; otherwise it will fail to find the libs – I assume this is is caused by setting `SONAME`, as the error message specifically mentions `.so.1.3.0` but I haven't been able to properly triage the issue.

`py-sequoia` now has its own version as noted in its `setup.py` (`0.1.0`), hence the version *decreased*.

Also, for future releases, I'll probably break this up into about half a dozen different ports and maybe keep `sequoia´ as a metaport with `OPTION`s for the different crates. `sqop` was already moved into its own repo upstream and isn't part of the sequoia port anymore. I'll add it back as its own port in the future.

Would be super nice if we could get this into the next quarterlies, but I totally understand if the remaining time is a bit short for that. ^_^;
Comment 1 Kubilay Kocak freebsd_committer freebsd_triage 2021-06-29 01:41:15 UTC
(In reply to phryk-ports from comment #0)

PORTEPOCH needs to be incremented when a version goes backward.

Do the changes pass QA (poudriere) for default and non-default Python versions?

If there's a changelog associated with this release, please include it in the URL field. 

If this is a bugfix only release, please set merge-quarterly to ? It can be merged anytime if so.
Comment 2 Charlie Li freebsd_committer 2022-05-21 06:10:08 UTC
Even though it's a monorepo, it looks like each component/crate can be built independently. The openpgp crate is now at 1.8.0 but for example sq is at 0.26.0. I feel like because of the version discrepancies between components/crates, separating them out might make sense. Thoughts?
Comment 3 Charlie Li freebsd_committer 2022-05-27 03:46:00 UTC
Created attachment 234248 [details]
security/sq v1

Played around a bit (not least because this is now a BUILD_DEPENDS for another port to update), looks like there's not much of a monorepo situation anymore. sq appears like the only packageable item from the sequoia repo, as the rest are rlibs. ffi, sqv, sqop, keyring-linter have their own individual repos, and python is part of the new ffi repo.

This patch creates a new security/sq, current version 0.26.0, for the epitomous command-line tool. openssl and openssl-sys crates are updated from those versions in Cargo.toml and have upstream patches (by yours truly) applied for proper build and operation with LibreSSL 3.4 and 3.5.

This successfully builds keyrings, joins and revokes keys as needed for the other port. Other functionality should work as intended.
Comment 4 phryk-ports 2022-05-27 05:49:44 UTC
(In reply to Charlie Li from comment #3)

Wow, that's already impressive but the libressl compat really bumps it up
another notch.

Yeah, the mono-repo situation is something the Sequoia team has been putting
quite a bit of effort in to rectify. There's already sequoia-sqv, sequoia-sop,
sequoia-keystore and by now a good bunch of others, too.

I initially gave up on this port because I just didn't find the energy to
figure out how to and then set up multiple build/test environments for QA.

Currently, I'm not even using sequoia for anything because sequoia-sop's
python bindings aren't finished yet, but I have hopes for that to change
some time this year.

Do you have previous experience with developing / packaging Rust?
Because if you do, you're probably more qualified on making decisions
regarding the packaging of Sequoia components than me. :P

With the number of Sequoia components already around, I think it might
be wise to add a common prefix to their port names, tho.
(i.e. security/sq -> security/sequoia-sq)

I'm gonna see that I get some time in on the weekend to review your patch,
but honestly I assume I'm not gonna find any issue besides the naming. :P

By the way, if you're interested in the Sequoia project, I can heartily
recommend joining #sequoia on OFTC, the devs are very open to questions
and generally a delight to interact with. :)
Comment 5 Charlie Li freebsd_committer 2022-05-28 02:04:45 UTC
(In reply to phryk-ports from comment #4)
Generally speaking, if cargo-install(1) doesn't have anything to do, ie no [[bin]] or [[example]] targets in Cargo.toml, there's nothing to package/port. Crates that are effectively Rust libraries (rlibs) are just built as part of those with/for executables or examples. So only sq in the sequoia repo ends up getting ported/packaged.

Just finished building ffi and openpgp-ffi, but the shared libraries are effectively unusable because SONAMEs aren't present, which prevents ldconfig from processing them. Will raise with upstream.

Not attached to any particular naming scheme, as long as it makes sense and we can work some Makefile variable games to make maintenance hopefully easier. If security/sequoia ends up becoming a meta-port after all this, not sure how the versioning will go, since each component is on different versions and defining crate dependencies (especially sequoia-openpgp) differently.

It's about time I get on OFTC in general :-)
Comment 6 Charlie Li freebsd_committer 2022-05-28 02:08:07 UTC
Created attachment 234276 [details]
security/sq v2

fix typo, move LLVM to BUILD_DEPENDS (readelf -d does not show dynamic linkage to LLVM), update libc and patch mio crates to use the correct kqueue API
Comment 7 phryk-ports 2022-06-05 21:30:31 UTC
For reference, vishwin and I had a conversation in Sequoias
IRC channel yesterday and we decided that he will take over
maintainership of these ports as I currently have neither
the time nor energy to actually *maintain* them and he
seems to be more experienced with both porting and Rust.
Comment 8 Dave Cottlehuber freebsd_committer 2023-04-07 09:32:31 UTC
both chameleon and sq build OOTB, at least on 14.0-CURRENT:

- https://gitlab.com/sequoia-pgp/sequoia-chameleon-gnupg
- https://gitlab.com/sequoia-pgp/sequoia-sq

I'm not really keen on the python part, but I can at least
get these 2 rusty parts into ports to start with. Any objections,
or do either of you have plans already?
Comment 9 Charlie Li freebsd_committer 2023-04-07 10:58:21 UTC
I have it working locally as well, since it's needed for archlinux-keyring, but still reworking the port bits mostly due to not everything having endpoints.
Comment 10 Charlie Li freebsd_committer 2023-06-09 04:05:12 UTC
So upstream have deprecated the FFI bits in favour of "point solutions", so that removes a complexity point I've been dealing with. This deprecation includes the existing Python bindings, for which PySequoia serves as the replacement. Only crates that contain executables will be ported.

For now, I will convert security/sequoia into a meta-port, structured similarly to graphics/gimp. Since we have only had sq ported before, it will serve as the meta-port's one dependency until other crates under the official sequoia umbrella are ported over.
Comment 11 commit-hook freebsd_committer 2023-06-09 05:34:03 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=3835bb252e91cda64657878b8438f6440342f516

commit 3835bb252e91cda64657878b8438f6440342f516
Author:     Charlie Li <vishwin@FreeBSD.org>
AuthorDate: 2023-06-09 05:20:21 +0000
Commit:     Charlie Li <vishwin@FreeBSD.org>
CommitDate: 2023-06-09 05:32:56 +0000

    security/sequoia: convert to meta-port and update

    sq split to security/sequoia-sq. More programs to be ported later.
    FFI deprecated upstream and removed from the port.

    PR: 256877
    Approved by: phryk-ports[at]wzff[dot]de (maintainer, transfer)
    Event: SouthEast LinuxFest 2023

 UPDATING                                           |  11 +
 security/Makefile                                  |   1 +
 security/sequoia-sq/Makefile (new)                 |  50 ++
 security/sequoia-sq/Makefile.crates (new)          | 439 ++++++++++
 security/sequoia-sq/distinfo (new)                 | 881 +++++++++++++++++++++
 security/sequoia-sq/pkg-descr (new)                |   5 +
 security/sequoia-sq/pkg-plist (new)                |  63 ++
 security/sequoia/Makefile                          | 337 +-------
 security/sequoia/distinfo (gone)                   | 551 -------------
 security/sequoia/files/patch-Makefile (gone)       |  11 -
 security/sequoia/files/patch-ffi_Makefile (gone)   |  11 -
 .../files/patch-openpgp-ffi_Makefile (gone)        |  11 -
 security/sequoia/files/patch-rust-1.64.0 (gone)    |  80 --
 security/sequoia/files/patch-sop_Makefile (gone)   |  12 -
 security/sequoia/files/patch-sqv_Makefile (gone)   |  12 -
 security/sequoia/files/patch-store_Makefile (gone) |  12 -
 security/sequoia/files/patch-tool_Makefile (gone)  |  12 -
 .../sequoia/files/sequoia-openpgp.pc.in (gone)     |  11 -
 security/sequoia/files/sequoia.pc.in (gone)        |  11 -
 security/sequoia/pkg-descr                         |   7 +-
 security/sequoia/pkg-plist (gone)                  |  29 -
 21 files changed, 1460 insertions(+), 1097 deletions(-)
Comment 12 commit-hook freebsd_committer 2023-06-09 05:34:04 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=bc106728715d27f7724f51e17e27b90a1b1c0369

commit bc106728715d27f7724f51e17e27b90a1b1c0369
Author:     Charlie Li <vishwin@FreeBSD.org>
AuthorDate: 2023-06-09 05:29:28 +0000
Commit:     Charlie Li <vishwin@FreeBSD.org>
CommitDate: 2023-06-09 05:32:57 +0000

    security/py-sequoia: remove

    Deprecated upstream; security/sequoia no longer includes the parts
    necessary for this to work. PySequoia is the designated replacement
    and will be ported later, and MOVED will be updated accordingly.

    PR: 256877
    Approved by: phryk-ports[at]wzff[dot]de (maintainer, transfer)
    Event: SouthEast LinuxFest 2023

 MOVED                                           |  1 +
 security/Makefile                               |  1 -
 security/py-sequoia/Makefile (gone)             | 32 -------------------------
 security/py-sequoia/distinfo (gone)             |  3 ---
 security/py-sequoia/files/patch-Makefile (gone) | 12 ----------
 security/py-sequoia/files/patch-setup.py (gone) | 11 ---------
 security/py-sequoia/pkg-descr (gone)            |  2 --
 7 files changed, 1 insertion(+), 61 deletions(-)
Comment 13 Charlie Li freebsd_committer 2023-06-09 05:39:03 UTC
Updated to sequoia-openpgp crate's nominal version 1.16.0, even though security/sequoia is a meta-port now. sq to 0.30.1. Expect the meta-port to feel like the xorg meta-ports where every program/component become OPTIONS.