Re: OpenSSH issue: 14-Current rejects non-publickey scp/ssh/rsync connectiosn all of the sudden

[FreeBSD User]

Am Thu, 9 Sep 2021 22:12:09 +0200
Philipp Ost  schrieb:

> On 9/9/21 9:15 PM, FreeBSD User wrote:
> [...]
> > What has changed in the recent 14-CURRENT OpenSSH update that dramatically 
> > that working
> > schematics do not work any more?  
> 
> OpenSSH has been updated to v8.7p1:
> 
> https://cgit.freebsd.org/src/commit/?id=19261079b74319502c6ffa1249920079f0f69a72
> 
> One of the more prominent changes is the deprecation of SHA1.
> 
> There's some additional information here: 
> https://lists.freebsd.org/archives/freebsd-hackers/2021-September/000289.html
> 
> HTH
> Philipp
> 

I was and I'm aware of the published changes and deprecating SHA1 would imply 
non-use of
SHA1-based public keys. But public key authentication works fine, for pure ssh 
and ssh-based
rsync (scp untested). Password authentication doesn't work anymore either for 
pure ssh, scp
and rsync. I can not find any hints to dramatic changes to that and this 
authentication scheme
doesn't even work with the standard/vanilla sshd_config for the 14-CURRENT 
server side.

And beware: this problem is present only in relations, were recent 14-CURRENT 
is the ssh
server.

oh

-- 
O. Hartmann

Re: OpenSSH issue: 14-Current rejects non-publickey scp/ssh/rsync connectiosn all of the sudden

[Ed Maste]

On Thu, 9 Sept 2021 at 15:18, FreeBSD User  wrote:
>
> /etc/ssh/sshd_config line 89: Unsupported option UsePAM

Sorry, it turns out I had the wrong version of config.h in my commit.

I'm running a build now and will commit it once a test with that
change passes. I will look into all of the reported issues, but I'd be
much obliged if you can rebuild sshd and try again (once the config.h
commit lands).

Re: killall, symlinks, and signal delivery?

[Steve Kargl]

On Wed, Sep 08, 2021 at 02:10:47AM +0100, Jamie Landeg-Jones wrote:
> Steve Kargl  wrote:
> 
> > Yes, that's likely.  So, it could be a change in behavior
> > for ImageMagick.  Your suggested ps command doesn't provide
> 
> I don't know when the change was made, but the pkg for ImageMagik 6.9.12.12
> has "display" as a stand-alone binary, whilst the pkg for 7.0.11.12 has it
> as a softlink.
> 
> So yeah, either an upstream change, or a port change.
> 

Yes, indeed, we have a winner.  On my laptop, I have ImageMagick6 and
on my desktop ImagMagick7.  'killall display' works as expected on
mu laptop and fails on my desktop.

Thanks for the insights!

-- 
Steve

Re: OpenSSH issue: 14-Current rejects non-publickey scp/ssh/rsync connectiosn all of the sudden

[Philipp Ost]

On 9/9/21 9:15 PM, FreeBSD User wrote:
[...]

What has changed in the recent 14-CURRENT OpenSSH update that dramatically that 
working
schematics do not work any more?


OpenSSH has been updated to v8.7p1:

https://cgit.freebsd.org/src/commit/?id=19261079b74319502c6ffa1249920079f0f69a72

One of the more prominent changes is the deprecation of SHA1.

There's some additional information here: 
https://lists.freebsd.org/archives/freebsd-hackers/2021-September/000289.html


HTH
Philipp

OpenSSH issue: 14-Current rejects non-publickey scp/ssh/rsync connectiosn all of the sudden

[FreeBSD User]

Hello,

after upgrading 14-CURRENT to recent sources September, the 8th 2021, we 
realizes today a
strange non-standard behaviour when connecting attempts from several clients to 
14-CURRENT
based machines were made involving sshd.

First discovered on 13-STABLE clients (NanoBSD, router/fw appliance). With 
non-public-key
authentication we copy the config partition tar'ed over to a backup system. 
This worked great
until yesterday. Today the connection is dropped immediately, /var/log/auth.log 
(sshd log on
14-CURRENT) states:

Sep  9 19:19:10 <4.6> thor sshd[1350]: Failed password for user01 from 
192.168.11.111 port
24332 ssh2

A usual ssh login attempt also fails this way:
Permission denied, please try again.

The same behaviour is to observe with Xubuntu 20.04 clients and several other 
FreeBSD
13.0-RELENG and 13-STABLE clients. Also 14-CURRENT-to-14-CURRENT connection 
attempts are
negative!

The only working scheme right now is public key authentication and that is for 
some scenarios
not applicable.

What has changed in the recent 14-CURRENT OpenSSH update that dramatically that 
working
schematics do not work any more?

By the way, on the target host's sshd, on all instances,

settings like these

[...]
PasswordAuthentication yes
ChallengeResponseAuthentication yes
UsePAM yes

are set explicitely, while "UsePAM" produces an error:

/etc/ssh/sshd_config line 89: Unsupported option UsePAM

this sound ridiculous, since the usage of that tag is documented in the man 
page as well as
present in the example sshd_config and set yes by default.

What is wrong here? How can the sshd issue be fixed?

Kind regards and thanks in advance,

O. Hartmann

-- 
O. Hartmann

FreeBSD Port: www/php74-opcache had to be disabled after "service apache24 reload" core dumped

[Bruce Cantrall]

Hi, Not sure where I should go to suggest a bug fix about a weird apache24 
reload issue.  
On FreeBSD 12.2 servers that run apache24, we recently noticed apache24 kept 
crashing when we tried to do a "service apache24 reload".  It would core dump 
and the only thing you could do is to restart it, which got it going again, but 
the next time you tried a reload it would crash again.  (We reload it twice a 
day in cron after updating Let's Encrypt certificates.)
We thought there is some issue with shared memory that caused the core dumps.  
This happened on multiple servers after an upgrade to a newer version of 
php74-opcache.  We had to disable opcache as the workaround.
Workaround to allow "service apache24 reload" to work again: vi 
/usr/local/etc/php/ext-10-opcache.ini and add following line:opcache.enable=0
and then restart apache24 then reload works.
Working version of apache24 and php74-opcache:
# uname -a && pkg info -x opcache apache24 php74-7.4FreeBSD server1 
12.2-RELEASE-p7 FreeBSD 12.2-RELEASE-p7 GENERIC  
amd64php74-opcache-7.4.22_1apache24-2.4.48mod_php74-7.4.22_1php74-7.4.22_1
broken version of apache24 and php74-opcache:
$ uname -a && pkg info -x opcache apache24 php74-7.4FreeBSD server3 
12.2-RELEASE-p7 FreeBSD 12.2-RELEASE-p7 GENERIC  amd64php74-opcache-7.4.23 
**apache24-2.4.48mod_php74-7.4.22_1php74-7.4.23
Debugger info:# gdb /usr/local/sbin/httpd /httpd.core
GNU gdb (GDB) 10.2 [GDB v10.2 for FreeBSD]
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd12.2".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/local/sbin/httpd...
(No debugging symbols found in /usr/local/sbin/httpd)
[New LWP 100953]
Core was generated by `/usr/local/sbin/httpd -DNOHTTPACCEPT'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x000801994080 in ?? () from /usr/local/libexec/apache24/libphp7.so
(gdb) where
#0  0x000801994080 in ?? () from /usr/local/libexec/apache24/libphp7.so
#1  0x0008022293ab in ?? () from /usr/local/lib/php/20190902/opcache.so
#2  0x000801c7bef6 in ?? () from /usr/local/libexec/apache24/libphp7.so
#3  0x000801c607d2 in zend_llist_apply_with_del () from 
/usr/local/libexec/apache24/libphp7.so
#4  0x000801c7bed7 in ?? () from /usr/local/libexec/apache24/libphp7.so
#5  0x000801bf5489 in php_module_startup () from 
/usr/local/libexec/apache24/libphp7.so
#6  0x000801d07bc5 in ?? () from /usr/local/libexec/apache24/libphp7.so
#7  0x000801d07426 in ?? () from /usr/local/libexec/apache24/libphp7.so
#8  0x0025c9cf in ap_run_post_config ()
#9  0x0025b7f6 in main ()
I hope this helps someone else.
Thanks,Bruce C

Re: ar: warning: can't open file: ccopy.pieo: No such file or directory

[FreeBSD User]

Am Wed, 11 Aug 2021 15:03:54 -0400
Ed Maste  schrieb:

> On Wed, 11 Aug 2021 at 05:41, FreeBSD User  wrote:
> >
> > Hallo,
> >
> > latest upgrade of CURRENT sources renders buildworld into failure, box is 
> > running
> > FreeBSD 14.0-CURRENT #1 main-n248614-67f508db84b: Wed Aug 11 07:29:11 CEST 
> > 2021 amd64:  
> 
> Assuming this was with BEARSSL enabled, it should be fixed with:
> 
> commit 879675e9a0d84880cad9834e2ef98e8724c5532c
> Author: Warner Losh 
> Date:   Wed Aug 11 10:59:28 2021 -0600
> 
> stand: Add MK_PIE=no to defs.mk
> 
> There's no need to build both pie and non-pie .o's for stand. There's
> some other build thing with MK_BEAR_SSL=yes and/or MK_LOADER_VERIEXEC=yes
> that causes the pie build to fail that the 'ar' stage now. Since we don't
> need the PIE stuff and the non-PIE stuff, disable PIE for the boot loader.
> 
> Reviewed by:emaste
> Sponsored by:   Netflix
> 

Hello again,

I think I face the very same problem on 14-CURRENT boxes building either 
13-STABLE sources or
13-STABLE poudriere jails, when on the 14-CURRENT box WITH_BEARSSL is enabled 
in the
14-CURRENT host's /etc/src.conf.

I have two scenarios:

Building 13-STABLE for FreeBSD-pkg-base (having WITH_BEARSSL enabled in the 
src.conf dor the
13-STABLE source tree) and

Building poudriere jail from a dedicated source tree for 13-STABLE
(/pool/sources/13-STABLE/src) with WITH_BEARSSL enabled. 

The latter scenario sounds ridiculous to have BEARSSL enabled, but we use the 
very same
src.conf file for both the packages for FreeBSD pkg base and so for the 
poudriere jail built
from the same source tree.

For a couple of weeks now I'm unable to build both the packages nor the jails.

The question would be: is the solution you offered above and fixed the problem 
I had initailly
also applicable to 13-STABLE without breakage of something else?

Tahnk you very much in advance,

O. Hartmann

 

-- 
O. Hartmann

Re: error installing stand/i386/loader_4th in HEAD

[Warner Losh]

On Thu, Sep 9, 2021, 10:03 AM Gary Jennejohn  wrote:

> On Thu, 9 Sep 2021 09:07:08 -0600
> Warner Losh  wrote:
>
> > On Thu, Sep 9, 2021, 7:11 AM Gary Jennejohn 
> wrote:
> >
> > > I got a very strange error while trying to make installworld on HEAD:
> > >
> > > stand/i386/loader_4th (install)
> > > /tmp/install.rIhHqnPC/sh: cc not found
> > > *** Error code 127
> > >
> > > This from a tree which I updated at 08:37 UTC.  According to uname -a
> > > the tree is at commit main-n249276-fc29a8b9d95.
> > >
> > > I booted the new kernel from this tree.
> > >
> > > I've never seen this error before.  Why in the world would install need
> > > cc?
> > >
> >
> > The usual cause of this error is time skew. There were some build issues
> > that I've fixed that I was sure I merged to stable/13, but I'll check
> > when I get home.
> >
>
> Thanks.  I'll check the times set under /usr/src and /usr/obj.
>

If you have a reliable way to reproduce this,  I'd be quite interested if
it isn't a typical "oops" on dates

Warner

-- 
> Gary Jennejohn
>

Re: error installing stand/i386/loader_4th in HEAD

[Gary Jennejohn]

On Thu, 9 Sep 2021 09:07:08 -0600
Warner Losh  wrote:

> On Thu, Sep 9, 2021, 7:11 AM Gary Jennejohn  wrote:
> 
> > I got a very strange error while trying to make installworld on HEAD:
> >
> > stand/i386/loader_4th (install)
> > /tmp/install.rIhHqnPC/sh: cc not found
> > *** Error code 127
> >
> > This from a tree which I updated at 08:37 UTC.  According to uname -a
> > the tree is at commit main-n249276-fc29a8b9d95.
> >
> > I booted the new kernel from this tree.
> >
> > I've never seen this error before.  Why in the world would install need
> > cc?
> >  
> 
> The usual cause of this error is time skew. There were some build issues
> that I've fixed that I was sure I merged to stable/13, but I'll check
> when I get home.
> 

Thanks.  I'll check the times set under /usr/src and /usr/obj.

-- 
Gary Jennejohn

Re: error installing stand/i386/loader_4th in HEAD

[Warner Losh]

On Thu, Sep 9, 2021, 7:11 AM Gary Jennejohn  wrote:

> I got a very strange error while trying to make installworld on HEAD:
>
> stand/i386/loader_4th (install)
> /tmp/install.rIhHqnPC/sh: cc not found
> *** Error code 127
>
> This from a tree which I updated at 08:37 UTC.  According to uname -a
> the tree is at commit main-n249276-fc29a8b9d95.
>
> I booted the new kernel from this tree.
>
> I've never seen this error before.  Why in the world would install need
> cc?
>

The usual cause of this error is time skew. There were some build issues
that I've fixed that I was sure I merged to stable/13, but I'll check
when I get home.

Note that I copied the contents of /usr/src/etc/mtree to /etc/mtree before
> starting the installation.
>

I don't think that matters

Warner

-- 
> Gary Jennejohn
>
>

Re: fetch -v error output broken?

[Baptiste Daroussin]

On Thu, Sep 09, 2021 at 04:00:39PM +0200, Stefan Esser wrote:
> I have just opened PR 258387 for this issue, which occurred during testing
> of a port with invalid MASTER_SITE.
> 
> The error output of "fetch -v" should be server messages, but it appears that
> the buffer gets overwritten with data of unknown origin (mostly NUL bytes), 
> e.g.:
> 
I figured the same this morning and fixed it in: 635eb7ac799

Best regards,
Bapt

fetch -v error output broken?

[Stefan Esser]

I have just opened PR 258387 for this issue, which occurred during testing
of a port with invalid MASTER_SITE.

The error output of "fetch -v" should be server messages, but it appears that
the buffer gets overwritten with data of unknown origin (mostly NUL bytes), 
e.g.:

$ fetch -v http://distcache.us-west.freebsd.org/x 2>&1 | hd
  72 65 73 6f 6c 76 69 6e  67 20 73 65 72 76 65 72  |resolving server|
0010  20 61 64 64 72 65 73 73  3a 20 64 69 73 74 63 61  | address: distca|
0020  63 68 65 2e 75 73 2d 77  65 73 74 2e 66 72 65 65  |che.us-west.free|
0030  62 73 64 2e 6f 72 67 3a  38 30 0a 72 65 71 75 65  |bsd.org:80.reque|
0040  73 74 69 6e 67 20 68 74  74 70 3a 2f 2f 64 69 73  |sting http://dis|
0050  74 63 61 63 68 65 2e 75  73 2d 77 65 73 74 2e 66  |tcache.us-west.f|
0060  72 65 65 62 73 64 2e 6f  72 67 2f 78 0a 0d 0a 00  |reebsd.org/x|
0070  67 69 6e 78 00 00 00 0a  34 30 34 20 4e 6f 74 20  |ginx404 Not |
0080  46 6f 75 6e 64 0d 0a 00  00 00 00 00 10 02 00 50  |Found..P|
0090  95 14 01 c9 00 00 00 00  00 00 00 00 0a 0d 0a 00  ||
00a0  74 6c 65 3e 34 30 34 20  4e 6f 74 20 46 6f 75 6e  |tle>404 Not Foun|
00b0  64 0d 0a 00 00 00 00 00  10 02 00 50 95 14 01 c9  |d..P|
00c0  00 00 00 00 00 00 00 00  0a 34 30 34 20 4e 6f 74  |.404 Not|
00d0  20 46 6f 75 6e 64 0d 0a  00 0a 00 00 00 00 00 10  | Found..|
00e0  02 00 50 95 14 01 c9 00  00 00 00 00 00 00 00 0a  |..P.|
00f0  6e 67 69 6e 78 0d 0a 00  3e 0d 0a 00 0a 00 00 00  |nginx...>...|
0100  00 00 10 02 00 50 95 14  01 c9 00 00 00 00 00 00  |.P..|
0110  00 00 0a 0d 0a 00 72 3e  6e 67 69 6e 78 0d 0a 00  |..r>nginx...|
0120  3e 0d 0a 00 0a 00 00 00  00 00 10 02 00 50 95 14  |>P..|
0130  01 c9 00 00 00 00 00 00  00 00 0a 0d 0a 00 72 3e  |..r>|
0140  6e 67 69 6e 78 0d 0a 00  3e 0d 0a 00 0a 00 00 00  |nginx...>...|
0150  00 00 10 02 00 50 95 14  01 c9 00 00 00 00 00 00  |.P..|
0160  00 00 0a 66 65 74 63 68  3a 20 68 74 74 70 3a 2f  |...fetch: http:/|
0170  2f 64 69 73 74 63 61 63  68 65 2e 75 73 2d 77 65  |/distcache.us-we|
0180  73 74 2e 66 72 65 65 62  73 64 2e 6f 72 67 2f 78  |st.freebsd.org/x|
0190  3a 20 4e 6f 74 20 46 6f  75 6e 64 0a  |: Not Found.|
019c

The expected output is returned by wget, e.g.:

$ wget -d http://distcache.us-west.freebsd.org/x
[...]
404 Not Found
Registered socket 3 for persistent reuse.
Skipping 146 bytes of body: [
404 Not Found

404 Not Found
nginx


] done.
2021-09-09 15:37:02 ERROR 404: Not Found.

Part of the HTML response can be found in the fetch output, too:

"r>nginx" is obviously a fragment of "nginx", but "r>nginx"
appears twice, 40 bytes apart.

"tle>404 Not Found" is a fragment of "404 Not Found", with "404
Not Found" appearing a total of 3 times ...

This could be a result of recent changes to the memcpy function, which used to
allow overlapping buffers, but does not anymore on -CURRENT.

But the 4 occurences of memcpy() in libfetch/http.c and libfetch/common.c seem
to be sane, and I did not look any further for the source of the data 
corruption.


OpenPGP_signature
Description: OpenPGP digital signature

error installing stand/i386/loader_4th in HEAD

[Gary Jennejohn]

I got a very strange error while trying to make installworld on HEAD:

stand/i386/loader_4th (install)
/tmp/install.rIhHqnPC/sh: cc not found
*** Error code 127

This from a tree which I updated at 08:37 UTC.  According to uname -a
the tree is at commit main-n249276-fc29a8b9d95.

I booted the new kernel from this tree.

I've never seen this error before.  Why in the world would install need
cc?

Note that I copied the contents of /usr/src/etc/mtree to /etc/mtree before
starting the installation.

-- 
Gary Jennejohn

Re: -CURRENT compilation time

[David Chisnall]

On 09/09/2021 00:04, Tomoaki AOKI wrote:

devel/ninja/Makefile has USES= python in it, so it maybe require python
to run or at least build.


You could probably remove that line without anyone noticing.  Ninja uses 
Python for precisely one thing (or, at least, did last time I looked):


There is a debugging mode that will generate a visualisation of all of 
the dependencies in the project and run a web server that allows you to 
view this visualisation in your web browser.


In about 10 years of using Ninja, I have used this functionality 
precisely once, and that was immediately after poking the code to find 
out why it had a Python dependency, discovering this mode existed, and 
looking to see what it did.


Nothing on the build paths depends on Python and Ninja doesn't require 
Python to build itself.


David