Upstream still ships the tarball, that's it, as per CVS log:
"primary distsite and homepage have gone away".
The only TCP port I've been able to detect (after producing traffing on a
variety of them) is SSH -- and that only worked after enabling IPv4.
Siphon does not seem to support/detect IPv6 at all and it's OS fingerprints
are extremely old; besides Gentoo we're the only ones still packaging it
according to https://repology.org/project/siphon/versions .
Fails with "-fno-common".
OK cwen
That's a NetBus 1.6 client... upstream's dead as in NXDOMAIN, we seem to be
the only folks still packaging it.
It has not changed in twenty years (surprise!) and basically only exists to
screw around with old old Windows boxes which... still run the server?
Fails with "-fno-common".
OK jsg
- typo in default config
- use directories setup in PLIST for suricata-update and default config
- add missing @sample
- tweak readme
- build with libmaxminddb support
- add debug packages
- reinstate patches to run as !root
I still see problems with this, after running for a few minutes I get a
'unlocking already-unlocked mutex' SIGABRT, same before/after this diff
Over half a year ago I dropped MAINTAINER on this port due to not using it
any longer. At that time it was already outdated. Noone spoke up to
update or even maintain it.
The new (unported) version 1.6.0 already suffers from TLS related build
failures, now there's another problem: it does not build with "-fcommon"
which will become a default compiler option in the tree.
If someone wants to fix both and get an up-to-date version running they
recover it from the attic.
OK tb
From https://lists.gnupg.org/pipermail/gnupg-announce/2021q1/000456.html:
There is a heap buffer overflow in libgcrypt due to an incorrect
assumption in the block buffer management code. Just decrypting some
data can overflow a heap buffer with attacker controlled data, no
verification or signature is validated before the vulnerability
occurs.
This comes from a new upstream, that focused on moving fwbuilder from
Qt4 to Qt5. There is no other functional changes to be expected by this
update.
OK rsadowski@
letsencrypt have already stopped allowing ACMEv1 for new domain
validations, and are now doing "brownouts" for all ACMEv1 access,
disabling it temporarily twice a month for increasing lengths of
time (6/24/48/72/120/168 hours) in the run up to disabling it
completely on June 1st.
Information for inst:py3-argon2-cffi-20.1.0
Comment:
argon2 password hashing for Python
Description:
Argon2 is a secure password hashing algorithm. Is is designed to
have both a configurable runtime as well as memory consumption.
The current workhorses of password hashing are unquestionably bcrypt
and PBKDF2. And while they're still fine to use, the password
cracking community embraced new technologies like GPUs and ASICs
to crack passwords in a highly parallel fashion.
An effective measure against extreme parallelism proved making
computation of password hashes also memory hard.
Between 2012 and 2015, the password hashing competition took place
to find a new, secure, and future-proof password hashing algorithm.
The winner of this competition was announced as Argon2.
Maintainer: The OpenBSD ports mailing-list <ports@openbsd.org>
WWW: https://argon2-cffi.readthedocs.io/
value (128) as discussed with kettenis@. turns out, the code to detect this on
the fly doesn't seem to work properly on linux too.
ok landry@ (MAINTAINER)
__GLIBC_PREREQ() being available.
furthermore, for powerpc64 we need to disable the generated assembler code for
it fails to assemble with llvm:
error: unexpected token at start of statement: .0:
that is to be revisited but for now libnettle (and thus gnutls) can be built again.
ok aja@ (MAINTAINER)
