FreeBSD ports you maintain which are out of date
Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/po...@freebsd.org.html Port| Current version | New version +-+ science/afni| 20.3.00 | afni_20.3.02 +-+ www/hotcrp | 2.94| 2.102 +-+ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt Reported by:portscout! ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Sudden trouble with net/rdesktop
On Fri, Nov 13, 2020 at 05:53:06PM +0300, Yuri Pankov wrote: > size is 128 now, so with digest of 256 we fail the ((len * 2) < size) > assertion, 257 works though (or changing the assertion to be <=). The call to gnutls_x509_crt_get_fingerprint adjusts the size of buf. I looked at the size immediately before the call to _utils_data_to_hex() for a couple of servers I have access to, and it was much smaller than 128 (20 and 32). I am not familiar enough with the internals of GnuTLS to know if it can be adjusted up as well, but as I stated before I think the intention was that 128 would be the largest size and the actual value of buf_size in the calls to _utils_data_to_hex() would depend on the actual size of the fingerprints of the cert. That appears to be why it worked before when digest was defined as 128 chars. My guess is Microsoft changed some parameters of the certificates in newer Windows versions and the resulting fingerprints are longer. > Actually, this does not look like a real fix. I have looked more into > it and something is still very wrong -- _utils_cert_get_info() calls > gnutls_x509_crt_get_fingerprint() and does NOT check the return value > while it is -72 (GNUTLS_E_ASN1_VALUE_NOT_VALID), while the only > *documented* return values are 0 (got fingerprint successfully) and -51 > (GNUTLS_E_SHORT_MEMORY_BUFFER, not enough buffer space). I don't know > if it was the same previously as I don't have a system to test against. > If yes, then this patch could be used in ports at least until upstream > fixes the problem properly; if no, then we would need a proper fix first. > > Also note that sha1 and sha256 fingerprints reported are the *same*, > which doesn't look right with this approach. Indeed, it would seem as though a good chunk of this code path makes assumptions that may no longer be valid and is perhaps in need of some rework. But for the purposes of patches in the ports tree, it seems like the best approach would be to change things by the minimal amount necessary to fix the issue. -- Greg Veldman g...@gregv.net ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Sudden trouble with net/rdesktop
Greg Veldman wrote:
On Fri, Nov 13, 2020 at 03:52:54PM +0300, Yuri Pankov wrote:
OK, I was able to reproduce this; actually, it hit that assertion for
all Windows 10 20H2 installs I have, all are updated to latest patches,
so I can't tell when this started to happen. Adding a debug print
before that assert() shows the following:
$ DISPLAY=mercury:0.0
/usr/ports/net/rdesktop/work/rdesktop-1.9.0/rdesktop orion
len=128 size=128
Assertion failed: ((len * 2) < size), function _utils_data_to_hex, file
utils.c, line 501.
So we need the len of 128 we need size of digest buf to be > 256, the
following patch worked for me:
polaris:ypankov:/usr/ports/net/rdesktop$ cat files/patch-utils.c
--- utils.c.orig2020-11-13 12:40:51 UTC
+++ utils.c
@@ -584,7 +584,7 @@ _utils_cert_get_info(gnutls_x509_crt_t cert, char *out
{
char buf[128];
size_t buf_size;
- char digest[128];
+ char digest[512];
gnutls_x509_dn_t dn;
time_t expire_ts, activated_ts;
This seems like a reasonable change, but I'll make one minor
note. Later on in _utils_cert_get_info() the contents of
digest are written to sha1 and sha256, which are both size
256. In the initial implementation both buf and digest are
of the same size, which would seem to indicate that buf was
not expected to be completely full (in fact less than half
full based on the assertion in _utils_data_to_hex()). However
if defined to 512 chars and ever somehow filled beyond 256
(in fact a bit less than that, since a static string is
prepended to the call to snprintf()), the writes to sha1 and
sha256 would be incomplete, which I haven't completely read
through but would very likely lead to Bad Things(tm) later on.
All this to say, perhaps a more conservative approach would be
to increase digest to 256 chars instead of 512. I don't currently
have a Windows 10 20H2 machine to test on, but would you mind
trying with 256 instead of 512 and see if that also fixes the
issue? If so, let me know and I'll submit a PR to get this
patch added.
size is 128 now, so with digest of 256 we fail the ((len * 2) < size)
assertion, 257 works though (or changing the assertion to be <=).
Actually, this does not look like a real fix. I have looked more into
it and something is still very wrong -- _utils_cert_get_info() calls
gnutls_x509_crt_get_fingerprint() and does NOT check the return value
while it is -72 (GNUTLS_E_ASN1_VALUE_NOT_VALID), while the only
*documented* return values are 0 (got fingerprint successfully) and -51
(GNUTLS_E_SHORT_MEMORY_BUFFER, not enough buffer space). I don't know
if it was the same previously as I don't have a system to test against.
If yes, then this patch could be used in ports at least until upstream
fixes the problem properly; if no, then we would need a proper fix first.
Also note that sha1 and sha256 fingerprints reported are the *same*,
which doesn't look right with this approach.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Sudden trouble with net/rdesktop
On Fri, Nov 13, 2020 at 03:52:54PM +0300, Yuri Pankov wrote:
> OK, I was able to reproduce this; actually, it hit that assertion for
> all Windows 10 20H2 installs I have, all are updated to latest patches,
> so I can't tell when this started to happen. Adding a debug print
> before that assert() shows the following:
>
> $ DISPLAY=mercury:0.0
> /usr/ports/net/rdesktop/work/rdesktop-1.9.0/rdesktop orion
> len=128 size=128
> Assertion failed: ((len * 2) < size), function _utils_data_to_hex, file
> utils.c, line 501.
>
> So we need the len of 128 we need size of digest buf to be > 256, the
> following patch worked for me:
>
> polaris:ypankov:/usr/ports/net/rdesktop$ cat files/patch-utils.c
> --- utils.c.orig2020-11-13 12:40:51 UTC
> +++ utils.c
> @@ -584,7 +584,7 @@ _utils_cert_get_info(gnutls_x509_crt_t cert, char *out
> {
> char buf[128];
> size_t buf_size;
> - char digest[128];
> + char digest[512];
> gnutls_x509_dn_t dn;
> time_t expire_ts, activated_ts;
This seems like a reasonable change, but I'll make one minor
note. Later on in _utils_cert_get_info() the contents of
digest are written to sha1 and sha256, which are both size
256. In the initial implementation both buf and digest are
of the same size, which would seem to indicate that buf was
not expected to be completely full (in fact less than half
full based on the assertion in _utils_data_to_hex()). However
if defined to 512 chars and ever somehow filled beyond 256
(in fact a bit less than that, since a static string is
prepended to the call to snprintf()), the writes to sha1 and
sha256 would be incomplete, which I haven't completely read
through but would very likely lead to Bad Things(tm) later on.
All this to say, perhaps a more conservative approach would be
to increase digest to 256 chars instead of 512. I don't currently
have a Windows 10 20H2 machine to test on, but would you mind
trying with 256 instead of 512 and see if that also fixes the
issue? If so, let me know and I'll submit a PR to get this
patch added.
Thanks.
--
Greg Veldman
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Sudden trouble with net/rdesktop
On 11/13/20 1:52 PM, Yuri Pankov wrote: So we need the len of 128 we need size of digest buf to be > 256, the following patch worked for me: You beat me to this :) I compiled rdesktop with DEBUG last night, but still it stripped the debug info. So I was not able to look at it yet. Also attached so you could simply drop it to files/ directory (if the list will pass it through). Works like a charm, thanks. Though I must admit I have no idea what changed exactly on Windows side caused the digest size to grow that much. Just out of curiosity, before the patch, I was able to connect to a a 19H2, but got the assert with two another boxes with the same version. I wasn't able to connect to any 20H1 and I have no 20H2 to try. bye av. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Sudden trouble with net/rdesktop
Andrea Venturoli wrote:
On 11/12/20 5:18 PM, Yuri Pankov wrote:
Could it be something that changed on remote side, e.g. any recent
updates?
Sure.
Most targets are Windows 10 machines, so they possibly updated to a
newer version, but I don't know.
One is Windows 2012, though, so I don't think that changed that much.
OK, I was able to reproduce this; actually, it hit that assertion for
all Windows 10 20H2 installs I have, all are updated to latest patches,
so I can't tell when this started to happen. Adding a debug print
before that assert() shows the following:
$ DISPLAY=mercury:0.0
/usr/ports/net/rdesktop/work/rdesktop-1.9.0/rdesktop orion
len=128 size=128
Assertion failed: ((len * 2) < size), function _utils_data_to_hex, file
utils.c, line 501.
So we need the len of 128 we need size of digest buf to be > 256, the
following patch worked for me:
polaris:ypankov:/usr/ports/net/rdesktop$ cat files/patch-utils.c
--- utils.c.orig2020-11-13 12:40:51 UTC
+++ utils.c
@@ -584,7 +584,7 @@ _utils_cert_get_info(gnutls_x509_crt_t cert, char *out
{
char buf[128];
size_t buf_size;
- char digest[128];
+ char digest[512];
gnutls_x509_dn_t dn;
time_t expire_ts, activated_ts;
Also attached so you could simply drop it to files/ directory (if the
list will pass it through). Though I must admit I have no idea what
changed exactly on Windows side caused the digest size to grow that much.
As a workaround, try increasing the buf size to e.g. 512 in
utils.c:_utils_cert_get_info().
Sorry, looks like I'm reading that backwards, and increasing the buf
size will actually make it worse.
BTW, did you previously have rdesktop compiled without DEBUG option,
so that assert() simply didn't fire, and now it's ON?
Actually I built it in poudriere *without* DEBUG option.
I might as well enable it and investigate, then.
Sorry, that was another shot in the dark, without actually trying
something, and wrong one at it.
--- utils.c.orig2020-11-13 12:40:51 UTC
+++ utils.c
@@ -584,7 +584,7 @@ _utils_cert_get_info(gnutls_x509_crt_t cert, char *out
{
char buf[128];
size_t buf_size;
- char digest[128];
+ char digest[512];
gnutls_x509_dn_t dn;
time_t expire_ts, activated_ts;
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
devel/rust-cbindgen fails to build
Is anyone else seeing that rust-cbindgen fails to build? root@kg-core1# cd /usr/ports/devel/rust-cbindgen root@kg-core1# make clean ===> Cleaning for rust-cbindgen-0.15.0_1 root@kg-core1# make [..] ===> Moving crates to /usr/ports/devel/rust-cbindgen/work/cbindgen-0.15.0/cargo-crates ===> Patching for rust-cbindgen-0.15.0_1 ===> rust-cbindgen-0.15.0_1 depends on package: rust>=1.47.0 - found ===> Configuring for rust-cbindgen-0.15.0_1 thread 'main' panicked at 'couldn't initialize the libgit2 library: -1, error: could not initialize openssl: error:1410D0B9:SSL routines:SSL_CTX_set_cipher_list:no cipher match', /usr/ports/lang/rust/work/rustc-1.47.0-src/vendor/libgit2-sys/lib.rs:3747:9 stack backtrace: note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace. *** Error code 101 Stop. make: stopped in /usr/ports/devel/rust-cbindgen This is on root@kg-core1# uname -a FreeBSD kg-core1.kg4.no 11.4-STABLE FreeBSD 11.4-STABLE #3 r362432: Sat Jun 20 12:51:06 CEST 2020 r...@kg-core1.kg4.no:/zs/usr/obj/usr/src/sys/GENERIC amd64 freshly updated ports tree today. -- Regards, Torfinn Ingolfsen ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FireFox keeps loosing data
On 13/11/20 07:58, Andrea Venturoli wrote: On 11/12/20 9:52 PM, Dave Horsfall wrote: Never use file locking on NFS. Period. One day it *will* bite you, due to some yet-to-be-discovered bug. In the meantime, feel free to ignore the advice of those who have been there before... Thanks for the advice. What protocol do you suggest, instead, for sharing data to a diskless client? I don't have a suggestion for "diskless" but since we're not i the 80's anymore, all machines come with some kind of disk controller and small disks (even decent SSD ones) don't cost so much, I'd suggest you install a minimal OS on the machine and use something like unison or syncthing to synchronize what you need. I'm doing this with my home directory with very good results. Personally I don't sync firefox and thunderbird profiles though, and have other exceptions (cache directories for npm and php-composer for example). I also think the synchronizing approach has advantage: Multiple copies of the data are usually a good thing, I can use this with my laptop too, just remember to sync it back as soon as I am back home, before using other machines! YMMV -- Guido Falsi ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
