Re: openssl in head returning "certificate expired" when it has not expired

[Benjamin Kaduk]

On Tue, Feb 02, 2021 at 03:48:06AM +, Rick Macklem wrote:
> Benjamin Kaduk wrote:
> >On Tue, Feb 02, 2021 at 12:46:25AM +, Rick Macklem wrote:
> >> I've recently been testing the daemons that do the
> >> non-application data stuff for nfs-over-tls with the
> >> openssl in head.
> >>
> >> These daemons work fine with both ports/security/openssl (openssl-1.1.1h)
> >> and ports/security/openssl-devel (openssl3-alpha).
> >>
> >> However, when linked to the openssl in head, the basic handshake
> >> and KTLS works, but the peer certificate from the client is reported
> >> as expired by SSL_get_verify_result(), although it is still valid.
> >> I added some debug output and the "notAfter" field of the
> >> certificate looks correct, so the certificate doesn't seem to be
> >> corrupted.
> >>
> >> I tried backporting the changes in crypto/x509 in head back
> >> into ports/security/openssl and it still worked, so those changes
> >> do not seem to have caused the problem.
> >> There are several differences in the configured options, but I cannot
> >> see any other differences between ports/security/openssl and
> >> what is in head that could cause this.
> >> (The options that differ seem related to old encryption types, etc.)
> >>
> >> Any other ideas for tracking this down?
> >
> >Is it perhaps related to https://github.com/openssl/openssl/issues/14036 ?
> Well, it is definitely due to a change in behaviour between 1.1.1h and 1.1.1i.
> I notices that ports/security/openssl has been upgraded to 1.1.1i and it
> exhibits the "expired" behaviour.
> 
> However, in my case, the certificate has not expired.
> The notAfter date is in 2022, but SSL_get_verify_results() returns
> X509_V_ERR_CERT_HAS_EXPIRED.

Is there an expired CA in the chain?

I suppose that reverting the commit from
https://github.com/openssl/openssl/pull/11359 (linked from the issue) would
probably be pretty easty to check.

-Ben
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: openssl in head returning "certificate expired" when it has not expired

[Rick Macklem]

Benjamin Kaduk wrote:
>On Tue, Feb 02, 2021 at 12:46:25AM +, Rick Macklem wrote:
>> I've recently been testing the daemons that do the
>> non-application data stuff for nfs-over-tls with the
>> openssl in head.
>>
>> These daemons work fine with both ports/security/openssl (openssl-1.1.1h)
>> and ports/security/openssl-devel (openssl3-alpha).
>>
>> However, when linked to the openssl in head, the basic handshake
>> and KTLS works, but the peer certificate from the client is reported
>> as expired by SSL_get_verify_result(), although it is still valid.
>> I added some debug output and the "notAfter" field of the
>> certificate looks correct, so the certificate doesn't seem to be
>> corrupted.
>>
>> I tried backporting the changes in crypto/x509 in head back
>> into ports/security/openssl and it still worked, so those changes
>> do not seem to have caused the problem.
>> There are several differences in the configured options, but I cannot
>> see any other differences between ports/security/openssl and
>> what is in head that could cause this.
>> (The options that differ seem related to old encryption types, etc.)
>>
>> Any other ideas for tracking this down?
>
>Is it perhaps related to https://github.com/openssl/openssl/issues/14036 ?
Well, it is definitely due to a change in behaviour between 1.1.1h and 1.1.1i.
I notices that ports/security/openssl has been upgraded to 1.1.1i and it
exhibits the "expired" behaviour.

However, in my case, the certificate has not expired.
The notAfter date is in 2022, but SSL_get_verify_results() returns
X509_V_ERR_CERT_HAS_EXPIRED.

rick

-Ben
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Setting for displaying utf8 characters on all vt consoles results in panic on 14-CURRENT and 13.0-ALPHA3

[Yasuhiro Kimura]

From: Toomas Soome via freebsd-current 
Subject: Re: Setting for displaying utf8 characters on all vt consoles results 
in panic on 14-CURRENT and 13.0-ALPHA3
Date: Tue, 2 Feb 2021 00:35:49 +0200

> Should be fixed on current now.

Confirmed. Would you please MFC to stable/13?

Best Regards.

---
Yasuhiro Kimura
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Failure of release build with release.sh on 14-CURRENT amd64

[Rodney W. Grimes]

On some day Glen Barber wrote:
> On Mon, Feb 01, 2021 at 09:38:33PM +, tech-lists wrote:
> > On Mon, Feb 01, 2021 at 09:27:44PM +, Glen Barber wrote:
> > > On Sun, Jan 31, 2021 at 03:30:14PM +, tech-lists wrote:
> > > > Found
> > > > A pre-built version of pkg could not be found for your system.
> > > > Consider changing PACKAGESITE or installing it from ports:
> > > > 'ports-mgmt/pkg'.
> > > > 
> > > > root@generic:/usr/src/release # which pkg
> > > > /usr/sbin/pkg
> > > > 
> > > 
> > > This is because the 14.0-CURRENT packages for arm64 take a significant
> > > amount of more time to build than x86.
> > 
> > Hi,
> > 
> > Is there a way of making it use the pkg which is already installed on the 
> > system
> > running make release?
> > 
> 
> No.  /usr/sbin/pkg is the bootstrap tool to install /usr/local/sbin/pkg.
> It does not have the same functionality.

One could build your own local pkg repository that contained pkg
and what ever other pkg's are needed during a make release and
modify the /etc/pkg/FreeBSD.conf file to point at it as a way
to work around this .

> Glen

-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: How to setup ZFS mirrored boot device

[joe mcguckin]

I did a scrub, it finished within 30 seconds.


But the error was that it could not find the boot device it was looking for. 
I’ve seen this before: If you create a boot device in slot 0 (gets named da0) 
then move that drive to a different slot,
FreeBSD will fail in the same manner.

Joe McGuckin
ViaNet Communications

j...@via.net
650-207-0372 cell
650-213-1302 office
650-969-2124 fax



> On Feb 1, 2021, at 4:34 PM, Tim Rice  wrote:
> 
> 
> 
> On 2/1/21 3:56 PM, joe mcguckin wrote:
>> I tried this but it’s not quite working.
>> 
>> LSI controller flashed with IT firmware.
>> 
>> 2) 1T SSD drives
>> 
>> During the install process, I select to create a mirrored ZFS root. It 
>> appears to be created 
>> and there is a zroot dataset. zpool status shows everythings ok.
>> 
>> Now it gets interesting:
>> 
>> I pull one drive after  poweron but before FreeBSD starts - everything boots 
>> ok, zpool status reports one drive missing and suggests that I replace the 
>> missing drive and do a “zpool online”
>> I do so and zpool reports everything’s ok.
>> 
>> Now lets reboot and just after Bios power on, pull drive 2. FreeBSD boots 
>> until it wants to mount the root partition, can’t find it, dumps me into a 
>> menual drive selection prompt.
>> 
>> Hmm, I thought the point of a mirror was that *either* drive could fail.
>> 
>> What am I doing wrong?
> You did wait for the resilver to complete after bringing the 1st drive
> back online
> before the 2nd test, right?
> 
>> 
>> Thanks,
>> 
>> Joe
>> 
>> 
>> Joe McGuckin
>> ViaNet Communications
>> 
>> j...@via.net
>> 650-207-0372 cell
>> 650-213-1302 office
>> 650-969-2124 fax
>> 
> -- 
> 
> Tim Rice
> tim.r...@xinuos.com
> 
> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: openssl in head returning "certificate expired" when it has not expired

[Benjamin Kaduk]

On Tue, Feb 02, 2021 at 12:46:25AM +, Rick Macklem wrote:
> I've recently been testing the daemons that do the
> non-application data stuff for nfs-over-tls with the
> openssl in head.
> 
> These daemons work fine with both ports/security/openssl (openssl-1.1.1h)
> and ports/security/openssl-devel (openssl3-alpha).
> 
> However, when linked to the openssl in head, the basic handshake
> and KTLS works, but the peer certificate from the client is reported
> as expired by SSL_get_verify_result(), although it is still valid.
> I added some debug output and the "notAfter" field of the
> certificate looks correct, so the certificate doesn't seem to be
> corrupted.
> 
> I tried backporting the changes in crypto/x509 in head back
> into ports/security/openssl and it still worked, so those changes
> do not seem to have caused the problem.
> There are several differences in the configured options, but I cannot
> see any other differences between ports/security/openssl and
> what is in head that could cause this.
> (The options that differ seem related to old encryption types, etc.)
> 
> Any other ideas for tracking this down?

Is it perhaps related to https://github.com/openssl/openssl/issues/14036 ?

-Ben
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

openssl in head returning "certificate expired" when it has not expired

[Rick Macklem]

I've recently been testing the daemons that do the
non-application data stuff for nfs-over-tls with the
openssl in head.

These daemons work fine with both ports/security/openssl (openssl-1.1.1h)
and ports/security/openssl-devel (openssl3-alpha).

However, when linked to the openssl in head, the basic handshake
and KTLS works, but the peer certificate from the client is reported
as expired by SSL_get_verify_result(), although it is still valid.
I added some debug output and the "notAfter" field of the
certificate looks correct, so the certificate doesn't seem to be
corrupted.

I tried backporting the changes in crypto/x509 in head back
into ports/security/openssl and it still worked, so those changes
do not seem to have caused the problem.
There are several differences in the configured options, but I cannot
see any other differences between ports/security/openssl and
what is in head that could cause this.
(The options that differ seem related to old encryption types, etc.)

Any other ideas for tracking this down?

Thanks, rick
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: How to setup ZFS mirrored boot device

[Tim Rice]

On 2/1/21 3:56 PM, joe mcguckin wrote:
> I tried this but it’s not quite working.
>
> LSI controller flashed with IT firmware.
>
> 2) 1T SSD drives
>
> During the install process, I select to create a mirrored ZFS root. It 
> appears to be created 
> and there is a zroot dataset. zpool status shows everythings ok.
>
> Now it gets interesting:
>
> I pull one drive after  poweron but before FreeBSD starts - everything boots 
> ok, zpool status reports one drive missing and suggests that I replace the 
> missing drive and do a “zpool online”
> I do so and zpool reports everything’s ok.
>
> Now lets reboot and just after Bios power on, pull drive 2. FreeBSD boots 
> until it wants to mount the root partition, can’t find it, dumps me into a 
> menual drive selection prompt.
>
> Hmm, I thought the point of a mirror was that *either* drive could fail.
>
> What am I doing wrong?
You did wait for the resilver to complete after bringing the 1st drive
back online
before the 2nd test, right?

>
> Thanks,
>
> Joe
>
>
> Joe McGuckin
> ViaNet Communications
>
> j...@via.net
> 650-207-0372 cell
> 650-213-1302 office
> 650-969-2124 fax
>
-- 

Tim Rice
tim.r...@xinuos.com


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

How to setup ZFS mirrored boot device

[joe mcguckin]

I tried this but it’s not quite working.

LSI controller flashed with IT firmware.

2) 1T SSD drives

During the install process, I select to create a mirrored ZFS root. It appears 
to be created 
and there is a zroot dataset. zpool status shows everythings ok.

Now it gets interesting:

I pull one drive after  poweron but before FreeBSD starts - everything boots 
ok, zpool status reports one drive missing and suggests that I replace the 
missing drive and do a “zpool online”
I do so and zpool reports everything’s ok.

Now lets reboot and just after Bios power on, pull drive 2. FreeBSD boots until 
it wants to mount the root partition, can’t find it, dumps me into a menual 
drive selection prompt.

Hmm, I thought the point of a mirror was that *either* drive could fail.

What am I doing wrong?

Thanks,

Joe


Joe McGuckin
ViaNet Communications

j...@via.net
650-207-0372 cell
650-213-1302 office
650-969-2124 fax



___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Setting for displaying utf8 characters on all vt consoles results in panic on 14-CURRENT and 13.0-ALPHA3

[Toomas Soome via freebsd-current]

> On 1. Feb 2021, at 05:35, Yasuhiro Kimura  wrote:
> 
> From: Yasuhiro Kimura mailto:y...@utahime.org>>
> Subject: Setting for displaying utf8 characters on all vt consoles results in 
> panic on 14-CURRENT and 13.0-ALPHA3
> Date: Mon, 01 Feb 2021 11:41:35 +0900 (JST)
> 
>> To display utf8 characters on all vt console I did following settings.
>> 
>> 1. Download GNU Unifont BDF file
>>   
>> (http://unifoundry.com/pub/unifont/unifont-13.0.05/font-builds/unifont-13.0.05.bdf.gz)
>> 2. gunzip unifont-13.0.05.bdf.gz
>> 3. vtfontcvt unifont-13.0.05.bdf unifont.fnt
>> 4. cp unifont.fnt /usr/share/vt/fonts
>> 5. Add 'allscreens_flags="-f 8x16 unifont.fnt"' to /etc/rc.conf
>> 6. Add 'hw.vga.textmode=0' to /boot/loader.conf.local
>> 7. shutdown -r now
>> 
>> On 12.2-RELEASE and 11.4-RELEASE it works as is expected. But on
>> 14-CURRENT(man) and 13.0-ALPHA3(stable/13) it result in kernel panic.
>> 
>> Screen shot of 14-CURRENT.
>> https://www.utahime.org/FreeBSD/panic.20210201.14-CURRENT.png
>> 
>> 14-CURRENT(main):
>> yasu@rolling-vm-freebsd1[1006]% uname -a
>> FreeBSD rolling-vm-freebsd1.home.utahime.org 14.0-CURRENT FreeBSD 
>> 14.0-CURRENT #0 main-n244517-f17fc5439f5: Mon Feb  1 10:55:51 JST 2021 
>> ro...@rolling-vm-freebsd1.home.utahime.org:/usr0/freebsd/src/obj/usr0/freebsd/src/git/amd64.amd64/sys/GENERIC
>>   amd64
>> 
>> 13.0-ALPHA3(stable/13):
>> yasu@rolling-vm-freebsd5[1005]% uname -a
>> FreeBSD rolling-vm-freebsd5.home.utahime.org 13.0-ALPHA3 FreeBSD 13.0-ALPHA3 
>> #0 stable/13-c256214-g40cb0344eb2: Mon Feb  1 11:30:28 JST 2021 
>> ro...@rolling-vm-freebsd5.home.utahime.org:/usr0/freebsd/src/obj/usr0/freebsd/src/git/amd64.amd64/sys/GENERIC
>>   amd64
> 
> I submitted this problem to Bugzilla.
> 
> Bug 253147 - Setting for displaying utf8 characters on all vt consoles
> results in panic on 14-CURRENT and 13.0-ALPHA3
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253147 
> 
> 
> ---
> Yasuhiro Kimura

Should be fixed on current now.

thanks,
toomas


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Failure of release build with release.sh on 14-CURRENT amd64

[Glen Barber]

On Mon, Feb 01, 2021 at 09:38:33PM +, tech-lists wrote:
> On Mon, Feb 01, 2021 at 09:27:44PM +, Glen Barber wrote:
> > On Sun, Jan 31, 2021 at 03:30:14PM +, tech-lists wrote:
> > > Found
> > > A pre-built version of pkg could not be found for your system.
> > > Consider changing PACKAGESITE or installing it from ports:
> > > 'ports-mgmt/pkg'.
> > > 
> > > root@generic:/usr/src/release # which pkg
> > > /usr/sbin/pkg
> > > 
> > 
> > This is because the 14.0-CURRENT packages for arm64 take a significant
> > amount of more time to build than x86.
> 
> Hi,
> 
> Is there a way of making it use the pkg which is already installed on the 
> system
> running make release?
> 

No.  /usr/sbin/pkg is the bootstrap tool to install /usr/local/sbin/pkg.
It does not have the same functionality.

Glen



signature.asc
Description: PGP signature

Re: Failure of release build with release.sh on 14-CURRENT amd64

[tech-lists]

On Mon, Feb 01, 2021 at 09:27:44PM +, Glen Barber wrote:

On Sun, Jan 31, 2021 at 03:30:14PM +, tech-lists wrote:

Found
A pre-built version of pkg could not be found for your system.
Consider changing PACKAGESITE or installing it from ports:
'ports-mgmt/pkg'.

root@generic:/usr/src/release # which pkg
/usr/sbin/pkg



This is because the 14.0-CURRENT packages for arm64 take a significant
amount of more time to build than x86.


Hi,

Is there a way of making it use the pkg which is already installed on the system
running make release?

thanks,
--
J.


signature.asc
Description: PGP signature

Re: Failure of release build with release.sh on 14-CURRENT amd64

[Glen Barber]

On Sun, Jan 31, 2021 at 03:30:14PM +, tech-lists wrote:
> Hello,
> 
> I also tried to build a release and failed. My context is different to
> yours, though. The failure error is different. Just thought I'd mention
> it as "make release on -current is broken for me as well". In my
> context, it ignores the installed pkg and tries, and fails to get a
> -current pkg binary from the repos.
> 
> Context is raspberry pi4/8GB
> git version is src.git as of 30/01/21 evening UTC
> 
> command used was: root@generic:/usr/src/release # sh release.sh -c
> arm64/RPI.conf
> 
> error:
> --- installdirs-CONFSDIR ---
> installing DIRS CONFSDIR
> install -N /scratch/usr/src/etc  -d -m 0755 -o root  -g wheel
> /scratch/etc/pkg
> ELF ldconfig path: /lib /usr/lib /usr/lib/compat
> Bootstrapping pkg from
> pkg+http://pkg.FreeBSD.org/FreeBSD:14:aarch64/latest, please wait...
> pkg: Error fetching
> http://pkg.FreeBSD.org/FreeBSD:14:aarch64/latest/Latest/pkg.txz: Not
> Found
> A pre-built version of pkg could not be found for your system.
> Consider changing PACKAGESITE or installing it from ports:
> 'ports-mgmt/pkg'.
> 
> root@generic:/usr/src/release # which pkg
> /usr/sbin/pkg
> 

This is because the 14.0-CURRENT packages for arm64 take a significant
amount of more time to build than x86.

Glen



signature.asc
Description: PGP signature

Re: Failure of release build with release.sh on 14-CURRENT amd64

[Glen Barber]

On Sun, Jan 31, 2021 at 04:29:09PM +0900, Yasuhiro Kimura wrote:
> Hello,
> 
> I tried release build with /usr/src/release/release.sh on 14-CURRENT
> amd64 under followin conditions.
> 
> * 14-CURRENT amd64
> * f17fc5439f5 + revert of 84eaf2ccc6a (Workaroud of the problem
>   reported as bug 253087 on Bugzilla)
> * No release.conf, everithing is default
> * /scratch is empty when build starts
> * /scratch/usr/doc is ba0831043d of main
> * /scratch/usr/ports is r563439 of head
> * /scratch/usr/src is 151ec796a23 of main
> * devel/git is installed but devel/subversion isn't
> 
> And the result is failure with following error messages.
> 
> --
> cd /usr/doc/en_US.ISO8859-1/htdocs/releases/14.0R &&  env 
> MAN4DIR=/usr/src/release/../share/man/man4  _BRANCH=CURRENT  make all install 
> clean "FORMATS=html txt"  INSTALL_COMPRESSED='' URLS_ABSOLUTE=YES 
> DOCDIR=/usr/obj/usr/src/amd64.amd64/
> release/rdoc  WEBDIR=/usr/doc 
> DESTDIR=/usr/obj/usr/src/amd64.amd64/release/rdoc
> cd: /usr/doc/en_US.ISO8859-1/htdocs/releases/14.0R: No such file or directory
> *** Error code 2
> 
> Stop.
> make[1]: stopped in /usr/src/release
> *** Error code 1
> 
> Stop.
> make: stopped in /usr/src/release
> --
> 
> Full buld log is
> 
> https://www.utahime.org/FreeBSD/release.sh.2021-01-31-09-10-35.log
> 
> (Caution: Size of the file is about 75MB)
> 
> Does this mean that release.sh is simply broken right now or I did
> something wrong?
> 

Setting NODOC=1 should workaround the problem for now, until the
conversion from XML to ASCIIDoc/Hugo is 100% complete.  (It is
effectively complete, but there are a few nits here and there that need
to be resolved.)

Glen



signature.asc
Description: PGP signature

Re: (n244517-f17fc5439f5) svn stuck forever in /usr/ports?

[Guido Falsi via freebsd-current]

On 01/02/21 04:24, Rick Macklem wrote:

Rick Macklem wrote:

Guido Falsi wrote:
[good stuff snipped]

Performed a full bisect. Tracked it down to commit aa906e2a4957, adding
KTLS support to embedded OpenSSL.

I filed a bug report about this:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253135


Apart from switching to svn:// scheme, another workaround is to build
base using WITHOUT_OPENSSL_KTLS.

Just fyi, when I tested the daemons I have for nfs-over-tls (which use ktls),
they acted like things were ok (no handshake problems), but the data
ended up on the wire unencrypted (nfs-over-tls doesn't do a SSL_write(),
so it depends on ktls to do the encryption).

Since these daemons work fine with openssl3 in ports/security/openssl-devel,
I suspect the ktls backport is not quite right. I've sent jhb@ email.

I was wrong on the above. I did a full buildworld/installworld and the daemons
now seem to work with the openssl in head/main.

Btw, did anyone try rebuilding svn from sources after doing
the system upgrade?
(The openssl library calls and .h files definitely changed.)



The problem happens with svnlite from base, which should have been 
rebuilt and reinstalled with the system upgrade.


I also tested with ports svn which I did rebuild in poudriere and force 
reinstalled.


So, actually yes I did rebuild it, but I could force a new rebuild just 
to be sure.


--
Guido Falsi 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"