Created attachment 224799 [details] Patch for libgcrypt Update libgcrypt to 1.9.3 PORTVERSION --> DISTVERSION as per Porter's Handbook Make static library optional and enabled by default Compile tested on 13.0-STABLE #0 stable/13-n245283-70a2e9a3d44 (arm64) (make, make check-plist, make test) Poudriere testport OK 12.2-RELEASE (amd64) Poudriere testport OK 11.4-RELEASE (amd64)
Why enable the static library by default?
I would preferably disable it by default however I wasn't sure about your opinion so I kept as close as possible to what current version in tree provides.
Sigh... actually it's not enabled by default :-) Sorry for the confusion
A preference is not a reason to change a port. A single person's preference, definitely not. 20 people, maybe. 40 people, yes. Secondly, I would have to defend that change when asked. I don't have a good reason. And, the only reason I do have is I have on PR. That isn't reason enough. So, why do you need static libraries as default? Next: DISTVERSION vs PORTVERSION. DISTVERSION is the current preferred approach but PORTVERSION was the old standard and according to section 5.2.2 is still acceptable. If or when the conversion becomes mandatory a wholesale change will be made.
Regarding not including static library, it's been discussed in #bsdports on EFNet and the general consensus from each discussion including ports committers and portmgr members is that static libraries should go (security mainly) which is why I opted it as optional. We are slowly transitioning towards that see ffmpeg, expat2 (commit message), libsamplerate, taglib and libsndfile to mentioned a few and most CMake based project doesn't provide a static lib at all. As for PORT vs DISTVERSION, I agree and since I already made changes I didn't see a reason not to adapt the new preferred way.
IRC. I haven't used IRC for 15 years or more. Typically static libraries are a security risk and do not benefit security. When binaries are statically linked any security advisory against the library requires that any applications that use the static library must be rebuilt. This was controversial thing, i.e. discussed widely on BUGTRAQ and BOS about 25 years ago, before BUGTRAQ (and CERT) became a USG thing in 2002 and BOS was still around. Static libraries are a security risk. When are static libraries a good idea? When one plans to distribute a single binary. For example on Linux. I build an app to run on all Linux distros, regardless of glibc or other distro differences. I also had some statically linked FreeBSD a.out apps I built years ago until a.out support as removed from FreeBSD. The other reason was something like xforward where you might want to run it on a gateway machine without X installed so that one can proxy X through a bastion host. Things like that. Sure, I'll add static library build as non-default option to libgcrypt.
Thanks for having a nice discussion regarding the suggested changes.
Friendly ping
Static should be on by default.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=527821a60c9f2e706a0549ac23c8ddc6d8b778c3 commit 527821a60c9f2e706a0549ac23c8ddc6d8b778c3 Author: Cy Schubert <cy@FreeBSD.org> AuthorDate: 2021-05-23 03:36:23 +0000 Commit: Cy Schubert <cy@FreeBSD.org> CommitDate: 2021-05-23 03:41:32 +0000 security/libgcrypt: Make static an option Static linked binaries, due to the fact that they're statically linked, can pose a security risk should a library be updated and depending software not be recompiled and linked. This was a hot topic on BUGTRAQ about 25 years ago. The default is to build static libraries so as not to alter the package avoiding a POLA violation. PR: 255735 Submitted by: Daniel Engberg <daniel.engberg.lists@pyret.net> (mostly) Reported by: Daniel Engberg <daniel.engberg.lists@pyret.net> Reviewed by: cy Tested by: cy MFH: 2021Q2 security/libgcrypt/Makefile | 8 ++++++-- security/libgcrypt/pkg-plist | 2 +- 2 files changed, 7 insertions(+), 3 deletions(-)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=865a2a94e8fd819d5598b3f2230db4e82ff7fc44 commit 865a2a94e8fd819d5598b3f2230db4e82ff7fc44 Author: Cy Schubert <cy@FreeBSD.org> AuthorDate: 2021-05-23 03:30:03 +0000 Commit: Cy Schubert <cy@FreeBSD.org> CommitDate: 2021-05-23 03:41:31 +0000 security/libgcrypt: update to 1.9.3 PR: 255735 Submitted by: Daniel Engberg <daniel.engberg.lists@pyret.net> Reviewed by: cy Tested by: cy MFH: 2021Q2 security/libgcrypt/Makefile | 3 +-- security/libgcrypt/distinfo | 6 +++--- security/libgcrypt/pkg-plist | 2 +- 3 files changed, 5 insertions(+), 6 deletions(-)
Committed (modified), thanks!
A commit in branch 2021Q2 references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=70b08e987327d237ba066bf3398b3e55675f9c76 commit 70b08e987327d237ba066bf3398b3e55675f9c76 Author: Cy Schubert <cy@FreeBSD.org> AuthorDate: 2021-05-23 03:36:23 +0000 Commit: Cy Schubert <cy@FreeBSD.org> CommitDate: 2021-06-03 13:59:23 +0000 security/libgcrypt: Make static an option Static linked binaries, due to the fact that they're statically linked, can pose a security risk should a library be updated and depending software not be recompiled and linked. This was a hot topic on BUGTRAQ about 25 years ago. The default is to build static libraries so as not to alter the package avoiding a POLA violation. PR: 255735 Submitted by: Daniel Engberg <daniel.engberg.lists@pyret.net> (mostly) Reported by: Daniel Engberg <daniel.engberg.lists@pyret.net> Reviewed by: cy Tested by: cy MFH: 2021Q2 (cherry picked from commit 527821a60c9f2e706a0549ac23c8ddc6d8b778c3) security/libgcrypt/Makefile | 8 ++++++-- security/libgcrypt/pkg-plist | 2 +- 2 files changed, 7 insertions(+), 3 deletions(-)
A commit in branch 2021Q2 references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=67967c72eab139d680eca82090bb4ccae34d7d05 commit 67967c72eab139d680eca82090bb4ccae34d7d05 Author: Cy Schubert <cy@FreeBSD.org> AuthorDate: 2021-05-23 03:30:03 +0000 Commit: Cy Schubert <cy@FreeBSD.org> CommitDate: 2021-06-03 13:59:17 +0000 security/libgcrypt: update to 1.9.3 PR: 255735 Submitted by: Daniel Engberg <daniel.engberg.lists@pyret.net> Reviewed by: cy Tested by: cy MFH: 2021Q2 (cherry picked from commit 865a2a94e8fd819d5598b3f2230db4e82ff7fc44) security/libgcrypt/Makefile | 3 +-- security/libgcrypt/distinfo | 6 +++--- security/libgcrypt/pkg-plist | 2 +- 3 files changed, 5 insertions(+), 6 deletions(-)