Re: [UPDATE] security/py-fido2 to 0.8.1

[Reyk Floeter]

On Thu, Dec 19, 2019 at 12:18:28PM -0600, Lucas Raab wrote:
> Hello,
> 
> Updated py-fido2 below and has been tested with a Yubikey 4 and 
> security/yubico/yubikey-manager. Note, either chmod the USB devices or
> run ykman with doas after the recent USB device permissions changes.
> 

py-fido2 needs to be updated to use fido(4) instead of probing uhid
devices (/dev/fido/X instead of /dev/uhidX).  Fido is 0666 so you
don't need 

This:
https://github.com/Yubico/python-fido2/blob/master/fido2/_pyu2f/openbsd.py

Like that:
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libfido2/src/hid_openbsd.c.diff?r1=1.1=1.2=h

btw. the py code suffers from a TOCTOU problem because it scans for
devices, closes them again and remembers the path (for example
/dev/uhid0), and opens them later by path name before use.  Nobody
knows if it is still the same USB device...

Reyk

> Index: security/py-fido2/Makefile
> ===
> RCS file: /cvs/ports/security/py-fido2/Makefile,v
> retrieving revision 1.1.1.1
> diff -u -p -r1.1.1.1 Makefile
> --- security/py-fido2/Makefile19 Nov 2019 18:52:50 -  1.1.1.1
> +++ security/py-fido2/Makefile19 Dec 2019 18:16:54 -
> @@ -2,8 +2,7 @@
>  
>  COMMENT =Python module to communicate with USB FIDO devices
>  
> -MODPY_EGG_VERSION =  0.7.3
> -
> +MODPY_EGG_VERSION =  0.8.1
>  DISTNAME =   fido2-${MODPY_EGG_VERSION}
>  PKGNAME =py-${DISTNAME}
>  
> Index: security/py-fido2/distinfo
> ===
> RCS file: /cvs/ports/security/py-fido2/distinfo,v
> retrieving revision 1.1.1.1
> diff -u -p -r1.1.1.1 distinfo
> --- security/py-fido2/distinfo19 Nov 2019 18:52:50 -  1.1.1.1
> +++ security/py-fido2/distinfo19 Dec 2019 18:16:54 -
> @@ -1,2 +1,2 @@
> -SHA256 (fido2-0.7.3.tar.gz) = i1kuwOUTSPKWNnBv4yZkI6DkHDXJ32OiWakUiEUMEoU=
> -SIZE (fido2-0.7.3.tar.gz) = 188262
> +SHA256 (fido2-0.8.1.tar.gz) = RJBo9odvOXyLuW68anXIHCaS8EUSbT8T7OIdQJrN98M=
> +SIZE (fido2-0.8.1.tar.gz) = 201198
> Index: security/py-fido2/pkg/PLIST
> ===
> RCS file: /cvs/ports/security/py-fido2/pkg/PLIST,v
> retrieving revision 1.1.1.1
> diff -u -p -r1.1.1.1 PLIST
> --- security/py-fido2/pkg/PLIST   19 Nov 2019 18:52:50 -  1.1.1.1
> +++ security/py-fido2/pkg/PLIST   19 Dec 2019 18:16:54 -
> @@ -24,6 +24,8 @@ lib/python${MODPY_VERSION}/site-packages
>  
> lib/python${MODPY_VERSION}/site-packages/fido2/${MODPY_PYCACHE}rpid.${MODPY_PYC_MAGIC_TAG}pyc
>  
> lib/python${MODPY_VERSION}/site-packages/fido2/${MODPY_PYCACHE}server.${MODPY_PYC_MAGIC_TAG}pyc
>  
> lib/python${MODPY_VERSION}/site-packages/fido2/${MODPY_PYCACHE}utils.${MODPY_PYC_MAGIC_TAG}pyc
> +lib/python${MODPY_VERSION}/site-packages/fido2/${MODPY_PYCACHE}webauthn.${MODPY_PYC_MAGIC_TAG}pyc
> +lib/python${MODPY_VERSION}/site-packages/fido2/${MODPY_PYCACHE}win_api.${MODPY_PYC_MAGIC_TAG}pyc
>  lib/python${MODPY_VERSION}/site-packages/fido2/_pyu2f/
>  lib/python${MODPY_VERSION}/site-packages/fido2/_pyu2f/__init__.py
>  
> ${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/fido2/_pyu2f/${MODPY_PYCACHE}/
> @@ -56,6 +58,8 @@ lib/python${MODPY_VERSION}/site-packages
>  lib/python${MODPY_VERSION}/site-packages/fido2/rpid.py
>  lib/python${MODPY_VERSION}/site-packages/fido2/server.py
>  lib/python${MODPY_VERSION}/site-packages/fido2/utils.py
> +lib/python${MODPY_VERSION}/site-packages/fido2/webauthn.py
> +lib/python${MODPY_VERSION}/site-packages/fido2/win_api.py
>  share/examples/${MODPY_PY_PREFIX}fido2/
>  share/examples/${MODPY_PY_PREFIX}fido2/acr122u.py
>  share/examples/${MODPY_PY_PREFIX}fido2/acr122usam.py
> @@ -64,4 +68,5 @@ share/examples/${MODPY_PY_PREFIX}fido2/c
>  share/examples/${MODPY_PY_PREFIX}fido2/get_info.py
>  share/examples/${MODPY_PY_PREFIX}fido2/hmac_secret.py
>  share/examples/${MODPY_PY_PREFIX}fido2/multi_device.py
> +share/examples/${MODPY_PY_PREFIX}fido2/resident_key.py
>  share/examples/${MODPY_PY_PREFIX}fido2/u2f_nfc.py
> 
> ok?
> 

Re: UPDATE: www/mozilla-firefox U2F/FIDO support - using fido(4)

[Reyk Floeter]

On Tue, Dec 10, 2019 at 01:57:42PM +, Reyk Floeter wrote:
> TL;DR: this is an experimental port update to add U2F/FIDO support and
...
> I've implemented the missing bits in the Rust crate that is
> responsible for accessing the USB HID devices, see
> https://github.com/reyk/authenticator-rs/tree/reyk/openbsd
> 

This updated version has some changes:
1. It uses the new fido(4) driver in OpenBSD-current instead of uhid(4).
2. It works under pledge(2), so it doesn't need any changes in pledge.main.
3. It works better under unveil(2) with the /dev/fido/ directory.
4. It fixes a TOCTOU problem that was given by the authenticator-rs design:
   the existing OS backends (such as freebsd) first scan for devices
   (in monitor) before they pass the device name (e.g. /dev/uhid0) to
   the Device struct that opens it on demand.  I've had the same approach
   in my earlier diff but now I open the devices in monitor and pass the
   fd to the Device struct instead of the (totally pointless) device name.

To test this diff, you need to upgrade to -current or to the latest
snapshot (Dec 18 or newer).

Known issues:

- If you're in the middle of the authentication (Firefox shows a
little fingerprint in the status bar), you cannot use SSH with U2F at
the same time.  The device can only be opened by one user at a time
and sometimes blocks it for a bit too long.  But once you've done the
authentication, firefox closes the device again and you should be fine
and there's no need to kill firefox for SSH.
- The device sometimes doesn't respond immediately.
- I didn't manage to run firefox with RUST_LOG=debug to see the
debug!() output of the authenticator module.  Any hints would be
welcome.

I'm working on an additional approach on top of fido(4) that
eventually helps to fix or mitigate the known issues.  So this diff
might not be the final concept or version, and I will not try to
upstream it yet.

Please test, for example:
https://webauthn.io/, first Register, then Login.

Reyk

Index: www/mozilla-firefox/Makefile
===
RCS file: /cvs/ports/www/mozilla-firefox/Makefile,v
retrieving revision 1.405
diff -u -p -u -p -r1.405 Makefile
--- www/mozilla-firefox/Makefile3 Dec 2019 17:00:46 -   1.405
+++ www/mozilla-firefox/Makefile18 Dec 2019 10:30:27 -
@@ -9,6 +9,7 @@ MOZILLA_VERSION =   71.0
 MOZILLA_BRANCH =   release
 MOZILLA_PROJECT =  firefox
 MOZILLA_CODENAME = browser
+REVISION = 0
 
 WRKDIST =  ${WRKDIR}/${MOZILLA_DIST}-${MOZILLA_DIST_VERSION:C/b[0-9]*//}
 HOMEPAGE = https://www.mozilla.org/firefox/
Index: www/mozilla-firefox/files/unveil.main
===
RCS file: /cvs/ports/www/mozilla-firefox/files/unveil.main,v
retrieving revision 1.1
diff -u -p -u -p -r1.1 unveil.main
--- www/mozilla-firefox/files/unveil.main   3 Dec 2019 17:00:46 -   
1.1
+++ www/mozilla-firefox/files/unveil.main   18 Dec 2019 10:30:27 -
@@ -2,6 +2,7 @@
 /dev/urandom r
 /dev/video rw
 /dev/video0 rw
+/dev/fido rw
 
 /etc/fonts r
 /etc/machine-id r
Index: www/mozilla-firefox/patches/patch-Cargo_lock
===
RCS file: www/mozilla-firefox/patches/patch-Cargo_lock
diff -N www/mozilla-firefox/patches/patch-Cargo_lock
--- /dev/null   1 Jan 1970 00:00:00 -
+++ www/mozilla-firefox/patches/patch-Cargo_lock18 Dec 2019 10:30:27 
-
@@ -0,0 +1,32 @@
+$OpenBSD$
+
+Index: Cargo.lock
+--- Cargo.lock.orig
 Cargo.lock
+@@ -144,7 +144,7 @@ dependencies = [
+ [[package]]
+ name = "authenticator"
+ version = "0.2.6"
+-source = "registry+https://github.com/rust-lang/crates.io-index;
++source = 
"git+https://github.com/reyk/authenticator-rs?rev=44cde6a41568954c88288ed81babc70bb27d79bf#44cde6a41568954c88288ed81babc70bb27d79bf;
+ dependencies = [
+  "bitflags 1.2.0 (registry+https://github.com/rust-lang/crates.io-index)",
+  "boxfnonce 0.0.3 (registry+https://github.com/rust-lang/crates.io-index)",
+@@ -1222,7 +1222,7 @@ dependencies = [
+  "audio_thread_priority 0.20.2 
(registry+https://github.com/rust-lang/crates.io-index)",
+  "audioipc-client 0.4.0",
+  "audioipc-server 0.2.3",
+- "authenticator 0.2.6 
(registry+https://github.com/rust-lang/crates.io-index)",
++ "authenticator 0.2.6 
(git+https://github.com/reyk/authenticator-rs?rev=44cde6a41568954c88288ed81babc70bb27d79bf)",
+  "bitsdownload 0.1.0",
+  "bookmark_sync 0.1.0",
+  "cert_storage 0.0.1",
+@@ -3812,7 +3812,7 @@ dependencies = [
+ "checksum atomic_refcell 0.1.0 
(registry+https://github.com/rust-lang/crates.io-index)" = 
"fb2dcb6e6d35f20276943cc04bb98e538b348d525a04ac79c10021561d202f21"
+ "checksum atty 0.2.11 
(registry+https://github.com/rust-lang/crates.io-inde

Re: UPDATE: www/mozilla-firefox U2F/FIDO support (WebAuthn)

[Reyk Floeter]

On Tue, Dec 10, 2019 at 04:33:01PM +0100, Landry Breuil wrote:
> On Tue, Dec 10, 2019 at 03:20:15PM +0000, Reyk Floeter wrote:
> > On Tue, Dec 10, 2019 at 02:39:20PM +, Stuart Henderson wrote:
> > > On 2019/12/10 13:57, Reyk Floeter wrote:
> > > > +# U2F/FIDO keys
> > > > +/dev/uhid0 rw
> > > > +/dev/uhid1 rw
> > > > +/dev/uhid2 rw
> > > > +/dev/uhid3 rw
> > > > +/dev/uhid4 rw
> > > > +/dev/uhid5 rw
> > > > +/dev/uhid6 rw
> > > > +/dev/uhid7 rw
> > > > +/dev/uhid8 rw
> > > > +/dev/uhid9 rw
> > > 
> > > BTW there are several entries in dmesglog with uhid18 (Microsoft Surface
> > > Type Cover) and one with uhid40 (headset + docking station + others).
> > > The 40 seems excessive but it might be worth going up to, say, 20.
> > > (Alternatively it could be dropped to 7 to align with the number of
> > > device nodes created by MAKEDEV by default ..)
> > > 
> > 
> > I feared that, OK.  Let's go for 20 in this case?
> > 
> > My authenticator-rs code initially scanned the /dev directory for uhid
> > devices but I changed it to probe the first 100 uhid devices to work
> > under unveil(2) (I didn't want to make /dev rx and there's no
> > unveil(2) way to "read the directory contents without allowing access
> > to its files").
> > 
> > > > +This currently only works with pledge.main = disable.
> > > 
> > > Another option would be to do this, and remove some lines from the 
> > > pkg-readme...
> > > 
> > 
> > Hehe, good point and I wouldn't mind.  But even if pledge(2) is
> > enabled with all of its classes, it still limits ioctls and the scope
> > of other syscalls.  I don't know, what do people think about this?
> 
> Well, i managed to have a 'video' pledge class, so you can probably get
> an 'uhidioctl' class :)
> 

btw., the ioctls match the ones that are done by libfido2:

- USB_GET_DEVICEINFO (libfido2 or authenticator-rs)
- USB_GET_REPORT_ID (libfido2 or authenticator-rs)
- USB_GET_REPORT_DESC (libusbhid, used by both)

All of them are read-only (IOR).

Reyk

Re: UPDATE: www/mozilla-firefox U2F/FIDO support (WebAuthn)

[Reyk Floeter]

On Tue, Dec 10, 2019 at 02:39:20PM +, Stuart Henderson wrote:
> On 2019/12/10 13:57, Reyk Floeter wrote:
> > +# U2F/FIDO keys
> > +/dev/uhid0 rw
> > +/dev/uhid1 rw
> > +/dev/uhid2 rw
> > +/dev/uhid3 rw
> > +/dev/uhid4 rw
> > +/dev/uhid5 rw
> > +/dev/uhid6 rw
> > +/dev/uhid7 rw
> > +/dev/uhid8 rw
> > +/dev/uhid9 rw
> 
> BTW there are several entries in dmesglog with uhid18 (Microsoft Surface
> Type Cover) and one with uhid40 (headset + docking station + others).
> The 40 seems excessive but it might be worth going up to, say, 20.
> (Alternatively it could be dropped to 7 to align with the number of
> device nodes created by MAKEDEV by default ..)
> 

I feared that, OK.  Let's go for 20 in this case?

My authenticator-rs code initially scanned the /dev directory for uhid
devices but I changed it to probe the first 100 uhid devices to work
under unveil(2) (I didn't want to make /dev rx and there's no
unveil(2) way to "read the directory contents without allowing access
to its files").

> > +This currently only works with pledge.main = disable.
> 
> Another option would be to do this, and remove some lines from the 
> pkg-readme...
> 

Hehe, good point and I wouldn't mind.  But even if pledge(2) is
enabled with all of its classes, it still limits ioctls and the scope
of other syscalls.  I don't know, what do people think about this?

Reyk

> diff -u -p -r1.1 pledge.main
> --- pledge.main   3 Dec 2019 17:00:46 -   1.1
> +++ pledge.main   10 Dec 2019 14:26:25 -
> @@ -1,24 +1 @@
> +disable
> -stdio
> -rpath
> -wpath
> -cpath
> -inet
> -proc
> -exec
> -prot_exec
> -flock
> -ps
> -sendfd
> -recvfd
> -dns
> -vminfo
> -tty
> -drm
> -unix
> -fattr
> -getpw
> -mcast
> -# only needed for WebRTC
> -video
> -# only needed if not running sndiod(8)
> -audio
> 

UPDATE: www/mozilla-firefox U2F/FIDO support (WebAuthn)

[Reyk Floeter]

Hi

TL;DR: this is an experimental port update to add U2F/FIDO support and
I'd appreciate testing and feedback.  See the issues below why this
needs further work and discussion.

I've attached an updated port for Firefox 71 that adds support for
U2F/FIDO USB security keys under OpenBSD.  Since everyone got such
security keys for OpenSSH now ;-), I'd also like to use them for web
authentication (WebAuthn) as a better alternative to (T)OTP or SMS.

I've implemented the missing bits in the Rust crate that is
responsible for accessing the USB HID devices, see
https://github.com/reyk/authenticator-rs/tree/reyk/openbsd

It does come with issues:

- Firefox uses "vendored" versions of the Rust crates; it includes the
source code of all dependencies in its tarball (which is a good
thing).  Updating the 'third_pary/rust/authenticator' makes the ports'
patches rather large and the goal should be to get it into upstream.

- In case you wonder about the Linux bits in the patches, it updates
it to a new version of authenticator-rs that includes some internal
changes.  Maintaining patches for the old one version would make it
much more difficult.

- It doesn't work with pledge(2).  As described in the package README
snippet below, the only way to use it is to disable 'pledge.main'.
I think there are three ways to deal with it:
1. Keep it as it is and let users disable 'pledge.main' manually if
   they need U2F/FIDO (which isn't happening all the time).
2. Add access to the required USB HID ioctls to a new pledge class.
3. Split authenticator into a fork+exec model where USB HID access is
   done by an external handler or daemon that runs without pledge.  This
   wouldn't be impossible but a lot more complicated and potentially
   difficult to get into upstream.  OpenSSH uses a similar model with
   /usr/libexec/ssh-sk-helper.

>From pkg/README:
> Web Authentication
> ==
> Support for web authentication (WebAuthn) with U2F/FIDO-compatible
> security keys is supported but requires direct access to the uhid(4)
> USB device layer.  This is currently not possible with the default
> sandbox under OpenBSD: the installed unveil(2) policy permits access
> to the first 10 '/dev/uhid*' devices but pledge(2) prevents the
> required USB/UHID ioctls.
> 
> To enable U2F/FIDO support, a) make sure that the user has read/write
> to '/dev/uhid*' (this is the case if the user is a member of group
> wheel) and b) set 'pledge.main' to 'disable'.  For example:
> 
> # mkdir /etc/firefox && echo disable > /etc/firefox/pledge.main
> 
> WARNING: While 'pledge.main' is already the weakest policy, compared
> to 'pledge.content' or 'pledge.gpu', disabling it weakens the
> sandboxed security of Firefox itself.  It does not alter the
> protection that is offered by unveil(2).

Even if we have to solve the issues first, I'd appreciate testing and
feedback.  It takes a bit long to build the www/mozilla-firefox port
(and don't forget to bump the ulimits first) but it is worth the
effort if you need U2F/FIDO.

You can use any U2F/FIDO key, such as modern YubiKeys, and test it on
pages like https://webauthn.io/ or
https://demo.yubico.com/webauthn-technical/.

Reyk
Index: www/mozilla-firefox/Makefile
===
RCS file: /cvs/ports/www/mozilla-firefox/Makefile,v
retrieving revision 1.405
diff -u -p -u -p -r1.405 Makefile
--- www/mozilla-firefox/Makefile3 Dec 2019 17:00:46 -   1.405
+++ www/mozilla-firefox/Makefile10 Dec 2019 13:55:19 -
@@ -9,6 +9,7 @@ MOZILLA_VERSION =   71.0
 MOZILLA_BRANCH =   release
 MOZILLA_PROJECT =  firefox
 MOZILLA_CODENAME = browser
+REVISION = 0
 
 WRKDIST =  ${WRKDIR}/${MOZILLA_DIST}-${MOZILLA_DIST_VERSION:C/b[0-9]*//}
 HOMEPAGE = https://www.mozilla.org/firefox/
Index: www/mozilla-firefox/files/unveil.main
===
RCS file: /cvs/ports/www/mozilla-firefox/files/unveil.main,v
retrieving revision 1.1
diff -u -p -u -p -r1.1 unveil.main
--- www/mozilla-firefox/files/unveil.main   3 Dec 2019 17:00:46 -   
1.1
+++ www/mozilla-firefox/files/unveil.main   10 Dec 2019 13:55:19 -
@@ -3,6 +3,18 @@
 /dev/video rw
 /dev/video0 rw
 
+# U2F/FIDO keys
+/dev/uhid0 rw
+/dev/uhid1 rw
+/dev/uhid2 rw
+/dev/uhid3 rw
+/dev/uhid4 rw
+/dev/uhid5 rw
+/dev/uhid6 rw
+/dev/uhid7 rw
+/dev/uhid8 rw
+/dev/uhid9 rw
+
 /etc/fonts r
 /etc/machine-id r
 
Index: www/mozilla-firefox/patches/patch-Cargo_lock
===
RCS file: www/mozilla-firefox/patches/patch-Cargo_lock
diff -N www/mozilla-firefox/patches/patch-Cargo_lock
--- /dev/null   1 Jan 1970 00:00:00 -
+++ www/mozilla-firefox/patches/patch-Cargo_lock10 Dec 2019 13:55:19 
-
@@ -0,0 +1,35 @@
+$OpenBSD$
+
+Add U2F/FIDO authenticator support for OpenBSD.
+This currently only works with pledge.main = disable.
+
+Index: Cargo.lock
+--- 

Re: update: lang/rust

[Reyk Floeter]

On Sun, Dec 08, 2019 at 12:30:09PM +0100, Sebastien Marie wrote:
> Hi,
> 
> Here the diff for updating lang/rust to 1.39.0
> 
> The patch took more time than expected to be done: I had problem with sparc64
> and I only achieved to have a workaround in order to avoid a SEGFAULT during 
> the
> build. I am suspecting some LLVM bug in sparc64, as the workaround is to build
> some part of rust with -O3 (else the generated code will SEGFAULT). I didn't
> really investigated at asm level.
> 
> The port was tested some times ago on amd64 (and build tested and all archs).
> 
> I intent to commit it in few days. But comments or OK are welcome :)
> 
> Thanks.

Lightly tested - looks good, compiles, and works fine.

- I was using 1.39-beta before (using your build-rust script) and had
  some issues - all of them disappeared with this port (libclang, cargo
  update, clippy, ...).

- Works fine with 1.39 async/await code, for example
  https://crates.io/crates/tokio-libtls v1.1.0

Thanks for your work!  I'm excited to see 1.39 in OpenBSD.

I cannot really judge the ports Makefile,
otherwise OK reyk@

> -- 
> Sebastien Marie
> 
> 
> Index: Makefile
> ===
> RCS file: /cvs/ports/lang/rust/Makefile,v
> retrieving revision 1.102
> diff -u -p -r1.102 Makefile
> --- Makefile  29 Sep 2019 08:23:17 -  1.102
> +++ Makefile  8 Dec 2019 10:55:23 -
> @@ -13,17 +13,17 @@ COMMENT-gdb = Rust debugger through gdb
>  COMMENT-clippy = Rust linter
>  COMMENT-rustfmt =Rust code formatter
>  
> -V =  1.38.0
> -CARGO_V =0.39.0
> +V =  1.39.0
> +CARGO_V =0.40.0
>  CLIPPY_V =   0.0.212
> -RUSTFMT_V =  1.4.4
> +RUSTFMT_V =  1.4.8
>  DISTNAME =   rustc-${V}-src
>  
>  # rustc bootstrap version
> -BV-aarch64 = 1.38.0-20190926
> -BV-amd64 =   1.38.0-20190924
> -BV-i386 =1.38.0-20190924
> -BV-sparc64 = 1.37.0-20190813
> +BV-aarch64 = 1.39.0-20191124
> +BV-amd64 =   1.39.0-20191122
> +BV-i386 =1.39.0-20191123
> +BV-sparc64 = 1.39.0-20191207
>  BV = ${BV-${MACHINE_ARCH}}
>  
>  PKGNAME =rust-${V}
> @@ -138,7 +138,7 @@ SUBST_VARS += WRKBUILD
>  post-patch:
>   sed -i 's/"files":{[^}]*}/"files":{}/' \
>   ${WRKSRC}/vendor/*/.cargo-checksum.json
> - ${SUBST_CMD} ${WRKSRC}/src/tools/cargo/tests/testsuite/support/paths.rs
> + ${SUBST_CMD} 
> ${WRKSRC}/src/tools/cargo/crates/cargo-test-support/src/paths.rs
>  
>  # - check datasize limit before configuring (and building)
>  pre-configure:
> Index: distinfo
> ===
> RCS file: /cvs/ports/lang/rust/distinfo,v
> retrieving revision 1.58
> diff -u -p -r1.58 distinfo
> --- distinfo  29 Sep 2019 08:23:17 -  1.58
> +++ distinfo  8 Dec 2019 10:55:23 -
> @@ -1,10 +1,10 @@
> -SHA256 (rust/rustc-1.38.0-src.tar.xz) = 
> OnmRqky0TvlB1xY25FqVRotSDcb8fPclNkklvT49OjQ=
> -SHA256 (rust/rustc-bootstrap-aarch64-1.38.0-20190926.tar.xz) = 
> K6z7+X02Zw6kzFdt93JoOhVFJmVI1tp2kcV3Ep07i1k=
> -SHA256 (rust/rustc-bootstrap-amd64-1.38.0-20190924.tar.xz) = 
> s7m04Xk4Rukj3of8sLaK2NRiRZoAEEaxeQ14zE7/42U=
> -SHA256 (rust/rustc-bootstrap-i386-1.38.0-20190924.tar.xz) = 
> p7GH8ebq4uh5OUGIK3qbmRoWnotASu9Z6K/nMOLX2Ck=
> -SHA256 (rust/rustc-bootstrap-sparc64-1.37.0-20190813.tar.xz) = 
> Mja3fEVQ6pD9cxq0ZfEX+O6QW+cVLpA9n5k67M6u0gU=
> -SIZE (rust/rustc-1.38.0-src.tar.xz) = 96163304
> -SIZE (rust/rustc-bootstrap-aarch64-1.38.0-20190926.tar.xz) = 179869984
> -SIZE (rust/rustc-bootstrap-amd64-1.38.0-20190924.tar.xz) = 195854424
> -SIZE (rust/rustc-bootstrap-i386-1.38.0-20190924.tar.xz) = 193885292
> -SIZE (rust/rustc-bootstrap-sparc64-1.37.0-20190813.tar.xz) = 77696860
> +SHA256 (rust/rustc-1.39.0-src.tar.xz) = 
> Sw27NWBwaHpgYDT3HcAyt4O7+LXT+f/znywfvE8XHCk=
> +SHA256 (rust/rustc-bootstrap-aarch64-1.39.0-20191124.tar.xz) = 
> d+u86EWh5RRFuzf3NbOkHPV+jT5ySxEkqnOgQgU+w1g=
> +SHA256 (rust/rustc-bootstrap-amd64-1.39.0-20191122.tar.xz) = 
> SKh/PBPnJkPT489dOjhwwVemVEOA/UL5rOzmXWjCw84=
> +SHA256 (rust/rustc-bootstrap-i386-1.39.0-20191123.tar.xz) = 
> rbXw6X+yJdoinB56eCQPkg6k8o1SJiUl4yzcnPr2Als=
> +SHA256 (rust/rustc-bootstrap-sparc64-1.39.0-20191207.tar.xz) = 
> zbSeowzoJp2uhgnIcmOHiLXTZTlsXa0SGS8pm77zyaw=
> +SIZE (rust/rustc-1.39.0-src.tar.xz) = 96495140
> +SIZE (rust/rustc-bootstrap-aarch64-1.39.0-20191124.tar.xz) = 182606628
> +SIZE (rust/rustc-bootstrap-amd64-1.39.0-20191122.tar.xz) = 198744372
> +SIZE (rust/rustc-bootstrap-i386-1.39.0-20191123.tar.xz) = 198502860
> +SIZE (rust/rustc-bootstrap-sparc64-1.39.0-20191207.tar.xz) = 225734860
> Index: patches/patch-src_bootstrap_bin_rustc_rs
> ===
> RCS file: /cvs/ports/lang/rust/patches/patch-src_bootstrap_bin_rustc_rs,v
> retrieving revision 1.12
> diff -u -p 

CVS: cvs.openbsd.org: ports

[Reyk Floeter]

CVSROOT:/cvs
Module name:ports
Changes by: r...@cvs.openbsd.org2019/11/29 12:01:02

Modified files:
sysutils/cloud-agent: Makefile distinfo 
sysutils/cloud-agent/pkg: PLIST 

Log message:
Update cloud-agent to 1.1.  The included cms binary is not needed anymore.

OK kn@

UPDATE: sysutils/cloud-agent

[Reyk Floeter]

Hi,

we have CMS (again), so there's no need to compile the built-in cms
binary in cloud-agent anymore. Yay!  The USE_LIBRESSL_CMS make flag is
only needed as long as opensslv.h reports <=3.0.2 as the version
number.

## v1.1 (2019-11-29)

* Append `/etc/resolv.conf.tail` to `/etc/resolv.conf` if it exists.
* Use `openssl cms` in LibreSSL >3.0.2 (starting with OpenBSD 6.6-current).

OK?

Reyk

Index: sysutils/cloud-agent/Makefile
===
RCS file: /cvs/ports/sysutils/cloud-agent/Makefile,v
retrieving revision 1.5
diff -u -p -u -p -r1.5 Makefile
--- sysutils/cloud-agent/Makefile   12 Jul 2019 20:49:40 -  1.5
+++ sysutils/cloud-agent/Makefile   29 Nov 2019 17:56:46 -
@@ -2,7 +2,7 @@
 
 COMMENT=   cloud provisioning for OpenBSD VMs
 
-V= 0.9
+V= 1.1
 DISTNAME=  cloud-agent-$V
 CATEGORIES=sysutils
 HOMEPAGE=  https://github.com/reyk/cloud-agent/
@@ -15,5 +15,8 @@ PERMIT_PACKAGE=   Yes
 MASTER_SITES=  ${HOMEPAGE}releases/download/v${V}/
 
 WANTLIB=   c crypto expat ssl tls util
+
+# This can be removed after LibreSSL >3.0.2 is released
+MAKE_FLAGS=USE_LIBRESSL_CMS=1
 
 .include 
Index: sysutils/cloud-agent/distinfo
===
RCS file: /cvs/ports/sysutils/cloud-agent/distinfo,v
retrieving revision 1.3
diff -u -p -u -p -r1.3 distinfo
--- sysutils/cloud-agent/distinfo   26 Jun 2019 14:02:36 -  1.3
+++ sysutils/cloud-agent/distinfo   29 Nov 2019 17:56:46 -
@@ -1,2 +1,2 @@
-SHA256 (cloud-agent-0.9.tar.gz) = wLO7B/lbf0UniI7lexIpIWjUwg+/5GNaZCUjjiEKsqo=
-SIZE (cloud-agent-0.9.tar.gz) = 137118
+SHA256 (cloud-agent-1.1.tar.gz) = mDvjUjeNkd/WWUZgOjt8DBIYyR7Gq/5jjFrSw3n69fg=
+SIZE (cloud-agent-1.1.tar.gz) = 136965
Index: sysutils/cloud-agent/pkg/PLIST
===
RCS file: /cvs/ports/sysutils/cloud-agent/pkg/PLIST,v
retrieving revision 1.1.1.1
diff -u -p -u -p -r1.1.1.1 PLIST
--- sysutils/cloud-agent/pkg/PLIST  16 May 2018 11:58:32 -  1.1.1.1
+++ sysutils/cloud-agent/pkg/PLIST  29 Nov 2019 17:56:46 -
@@ -1,4 +1,3 @@
 @comment $OpenBSD: PLIST,v 1.1.1.1 2018/05/16 11:58:32 reyk Exp $
-@bin bin/cms
 @bin libexec/cloud-agent
 @man man/man8/cloud-agent.8

CVS: cvs.openbsd.org: ports

[Reyk Floeter]

CVSROOT:/cvs
Module name:ports
Changes by: r...@cvs.openbsd.org2019/06/26 08:02:36

Modified files:
sysutils/cloud-agent: Makefile distinfo 

Log message:
Update cloud-agent to v0.9 and adjust WANTLIB.

OK sthen@

UPDATE: sysutils/cloud-agent (v0.9)

[Reyk Floeter]

Hi,

I've released a new version of cloud-agent.

## v0.9 (2019-06-26)

* Added support for `-c` to specify the probing order of different cloud stacks.
* Added support for OpenNebula's START_SCRIPT methods (user-data alike).
* Added support for OpenNebula's USERNAME method.
* Added support for generating a default user password and writing it into
  `~/.ssh/authorized_keys`.
* Fixed handling of OpenNebula SSH_PUBLIC_KEY entries with multiple keys.
* Improved documentation, added `CHANGELOG.md` file.

OK?

Reyk

Index: sysutils/cloud-agent/Makefile
===
RCS file: /cvs/ports/sysutils/cloud-agent/Makefile,v
retrieving revision 1.3
diff -u -p -u -p -r1.3 Makefile
--- sysutils/cloud-agent/Makefile   3 Jun 2019 13:42:49 -   1.3
+++ sysutils/cloud-agent/Makefile   26 Jun 2019 13:00:17 -
@@ -2,7 +2,7 @@
 
 COMMENT=   cloud provisioning for OpenBSD VMs
 
-V= 0.8
+V= 0.9
 DISTNAME=  cloud-agent-$V
 CATEGORIES=sysutils
 HOMEPAGE=  https://github.com/reyk/cloud-agent/
Index: sysutils/cloud-agent/distinfo
===
RCS file: /cvs/ports/sysutils/cloud-agent/distinfo,v
retrieving revision 1.2
diff -u -p -u -p -r1.2 distinfo
--- sysutils/cloud-agent/distinfo   3 Jun 2019 13:42:49 -   1.2
+++ sysutils/cloud-agent/distinfo   26 Jun 2019 13:00:17 -
@@ -1,2 +1,2 @@
-SHA256 (cloud-agent-0.8.tar.gz) = cj9SOZvbaxd/OVBo1xtxF7uxI3uwIn7ftiiRc4cP94Q=
-SIZE (cloud-agent-0.8.tar.gz) = 132601
+SHA256 (cloud-agent-0.9.tar.gz) = wLO7B/lbf0UniI7lexIpIWjUwg+/5GNaZCUjjiEKsqo=
+SIZE (cloud-agent-0.9.tar.gz) = 137118

CVS: cvs.openbsd.org: ports

[Reyk Floeter]

CVSROOT:/cvs
Module name:ports
Changes by: r...@cvs.openbsd.org2019/06/03 07:42:49

Modified files:
sysutils/cloud-agent: Makefile distinfo 
sysutils/cloud-agent/pkg: DESCR 

Log message:
Update cloud-agent to v0.8

This release unbreaks the build with recent LibreSSL and adds support
for OpenNebula and optional disk resizing.

OK kn@

UPDATE: sysutils/cloud-agent

[Reyk Floeter]

Hi,

Update cloud-agent to v0.8.

This release includes the following fixes:

* Builds with LibreSSL on OpenBSD 6.5 and newer
* Unbreaks OpenStack support

It includes the following enhancements:

* Support for growing the disk and the last partition of the root disk
  (disabled by default)
* Improved OpenNebula support

OK?

Reyk

Index: sysutils/cloud-agent/Makefile
===
RCS file: /cvs/ports/sysutils/cloud-agent/Makefile,v
retrieving revision 1.2
diff -u -p -u -p -r1.2 Makefile
--- sysutils/cloud-agent/Makefile   9 Nov 2018 10:08:20 -   1.2
+++ sysutils/cloud-agent/Makefile   3 Jun 2019 13:25:05 -
@@ -1,10 +1,8 @@
 # $OpenBSD: Makefile,v 1.2 2018/11/09 10:08:20 sthen Exp $
 
-BROKEN=needs to adapt to libressl changes
-
 COMMENT=   cloud provisioning for OpenBSD VMs
 
-V= 0.6
+V= 0.8
 DISTNAME=  cloud-agent-$V
 CATEGORIES=sysutils
 HOMEPAGE=  https://github.com/reyk/cloud-agent/
Index: sysutils/cloud-agent/distinfo
===
RCS file: /cvs/ports/sysutils/cloud-agent/distinfo,v
retrieving revision 1.1.1.1
diff -u -p -u -p -r1.1.1.1 distinfo
--- sysutils/cloud-agent/distinfo   16 May 2018 11:58:32 -  1.1.1.1
+++ sysutils/cloud-agent/distinfo   3 Jun 2019 13:25:05 -
@@ -1,2 +1,2 @@
-SHA256 (cloud-agent-0.6.tar.gz) = HDtRHrNAFRNqAvg9BU+qbY/jRR+IN6As3zyTD5sFX58=
-SIZE (cloud-agent-0.6.tar.gz) = 127325
+SHA256 (cloud-agent-0.8.tar.gz) = cj9SOZvbaxd/OVBo1xtxF7uxI3uwIn7ftiiRc4cP94Q=
+SIZE (cloud-agent-0.8.tar.gz) = 132601
Index: sysutils/cloud-agent/pkg/DESCR
===
RCS file: /cvs/ports/sysutils/cloud-agent/pkg/DESCR,v
retrieving revision 1.1.1.1
diff -u -p -u -p -r1.1.1.1 DESCR
--- sysutils/cloud-agent/pkg/DESCR  16 May 2018 11:58:32 -  1.1.1.1
+++ sysutils/cloud-agent/pkg/DESCR  3 Jun 2019 13:25:05 -
@@ -1,3 +1,3 @@
 This is a simple OpenBSD-specific agent that handles provisioning and
 cloud initialization on clouds such as Microsoft Azure, Amazon AWS,
-Apache CloudStack, or OpenStack.
+Apache CloudStack, OpenNebula, or OpenStack.

Re: Update vmm-firmware port

[Reyk Floeter]

> Am 09.12.2018 um 14:01 schrieb Claudio Jeker :
> 
>> On Sun, Dec 09, 2018 at 01:44:07PM +0100, Reyk Floeter wrote:
>> Hi,
>> 
>> I don’t understand - does this turn on more of these annoying debug
>> messages like “Boot from” by default again?
>> 
> 
> If CONFIG_DEBUG_LEVEL is kept at -1 then the output will be:
> 
> Connected to /dev/ttypi (speed 115200)
> Booting from Hard Disk...
> Using drive 0, partition 3.
> Loading..
> probing: pc0 com0 mem[638K 510M a20=on] 
> disk: hd0+
>>> OpenBSD/amd64 BOOT 3.41
> -
> com0: 115200 baud
> switching console to com0
>>> OpenBSD/amd64 BOOT 3.41
> boot> 
> 
> Since I plan to add bootorder support I think it is a useful message:
> 
> Connected to /dev/ttypi (speed 115200)
> Booting from DVD/CD...
> CD-ROM: E0
> Loading /6.4/AMD64/CDBOOT
> probing: pc0 com0 mem[638K 510M a20=on]
> disk: hd0+ cd0
>>> OpenBSD/amd64 CDBOOT 3.40
> boot>
> 
> Makes it easier to know what SeaBIOS selected to boot from.
> But honestly if this is the bikeshed to work on then I can readd the
> boot.c diff since honestly that is absolutly unimportant.
> 

It’s not a bikeshed since I intentionally added this diff to remove the debug 
messages before.

And we know from the later messages if it selected CDROM, HDD, etc. So please 
keep the diff that removes it.

Otherwise OK reyk@

>> Reyk
>> 
>>> Am 09.12.2018 um 12:19 schrieb Claudio Jeker :
>>> 
>>> I started looking at supporting fw_cfg in vmd. Now to make this work with
>>> SeaBIOS there are a few fixes needed. First of all the way it reads the
>>> FW_CFG_DATA port is not supported by vmm(4) (problem whith 'rep insb' on
>>> IO ports). Additionally this cleans up some of the patches which I think
>>> are not needed if the setting of screen-and-debug is changed. At least I
>>> no longer see double printing of messages.
>>> I enabled CONFIG_BOOTORDER because this is what I would like to tweak.
>>> The CONFIG_DEBUG_LEVEL can be taken out before commit but it helped me
>>> debugging this. Once vmd uses fw_cfg more of the patches can be removed.
>>> 
>>> -- 
>>> :wq Claudio
>>> 
>>> Index: Makefile
>>> ===
>>> RCS file: /cvs/ports/sysutils/firmware/vmm/Makefile,v
>>> retrieving revision 1.15
>>> diff -u -p -r1.15 Makefile
>>> --- Makefile21 Nov 2018 00:26:05 -1.15
>>> +++ Makefile9 Dec 2018 11:09:05 -
>>> @@ -13,7 +13,7 @@ CC =/usr/bin/gcc
>>> FW_DRIVER=vmm
>>> FW_VER=1.11.0
>>> SB_VER=20100422
>>> -REVISION=0
>>> +REVISION=1
>>> DISTNAME=seabios-${FW_VER}
>>> DISTFILES=${DISTNAME}${EXTRACT_SUFX} \
>>>   sgabios-20100422{23d474943dcd55d0550a3d20b3d30e9040a4f15b}.tar.gz:0
>>> Index: files/config
>>> ===
>>> RCS file: /cvs/ports/sysutils/firmware/vmm/files/config,v
>>> retrieving revision 1.6
>>> diff -u -p -r1.6 config
>>> --- files/config11 Jul 2018 09:09:46 -1.6
>>> +++ files/config7 Dec 2018 20:34:05 -
>>> @@ -15,7 +15,7 @@ CONFIG_QEMU_HARDWARE=y
>>> # CONFIG_THREADS is not set
>>> # CONFIG_RELOCATE_INIT is not set
>>> # CONFIG_BOOTMENU is not set
>>> -# CONFIG_BOOTORDER is not set
>>> +CONFIG_BOOTORDER=y
>>> # CONFIG_ENTRY_EXTRASTACK is not set
>>> CONFIG_MALLOC_UPPERMEMORY=y
>>> CONFIG_ROM_SIZE=0
>>> @@ -92,7 +92,7 @@ CONFIG_VGA_EXTRA_STACK_SIZE=512
>>> #
>>> # Debugging
>>> #
>>> -CONFIG_DEBUG_LEVEL=-1
>>> +CONFIG_DEBUG_LEVEL=1
>>> CONFIG_DEBUG_SERIAL=y
>>> CONFIG_DEBUG_SERIAL_PORT=0x3f8
>>> CONFIG_DEBUG_IO=n
>>> Index: patches/patch-src_boot_c
>>> ===
>>> RCS file: patches/patch-src_boot_c
>>> diff -N patches/patch-src_boot_c
>>> --- patches/patch-src_boot_c11 Jul 2018 09:09:46 -1.1
>>> +++ /dev/null1 Jan 1970 00:00:00 -
>>> @@ -1,43 +0,0 @@
>>>  src/boot.c.origTue Jul 10 14:52:11 2018
>>> -+++ src/boot.cTue Jul 10 14:53:18 2018
>>> -@@ -659,7 +659,7 @@ boot_cdrom(struct drive_s *drive)
>>> - {
>>> - if (! CONFIG_CDROM_BOOT)
>>> - return;
>>> --printf("Booting from DVD/CD...\n");
>>> -+dpr

Re: Update vmm-firmware port

[Reyk Floeter]

Hi,

I don’t understand - does this turn on more of these annoying debug messages 
like “Boot from” by default again?

Reyk

> Am 09.12.2018 um 12:19 schrieb Claudio Jeker :
> 
> I started looking at supporting fw_cfg in vmd. Now to make this work with
> SeaBIOS there are a few fixes needed. First of all the way it reads the
> FW_CFG_DATA port is not supported by vmm(4) (problem whith 'rep insb' on
> IO ports). Additionally this cleans up some of the patches which I think
> are not needed if the setting of screen-and-debug is changed. At least I
> no longer see double printing of messages.
> I enabled CONFIG_BOOTORDER because this is what I would like to tweak.
> The CONFIG_DEBUG_LEVEL can be taken out before commit but it helped me
> debugging this. Once vmd uses fw_cfg more of the patches can be removed.
> 
> -- 
> :wq Claudio
> 
> Index: Makefile
> ===
> RCS file: /cvs/ports/sysutils/firmware/vmm/Makefile,v
> retrieving revision 1.15
> diff -u -p -r1.15 Makefile
> --- Makefile21 Nov 2018 00:26:05 -1.15
> +++ Makefile9 Dec 2018 11:09:05 -
> @@ -13,7 +13,7 @@ CC =/usr/bin/gcc
> FW_DRIVER=vmm
> FW_VER=1.11.0
> SB_VER=20100422
> -REVISION=0
> +REVISION=1
> DISTNAME=seabios-${FW_VER}
> DISTFILES=${DISTNAME}${EXTRACT_SUFX} \
>sgabios-20100422{23d474943dcd55d0550a3d20b3d30e9040a4f15b}.tar.gz:0
> Index: files/config
> ===
> RCS file: /cvs/ports/sysutils/firmware/vmm/files/config,v
> retrieving revision 1.6
> diff -u -p -r1.6 config
> --- files/config11 Jul 2018 09:09:46 -1.6
> +++ files/config7 Dec 2018 20:34:05 -
> @@ -15,7 +15,7 @@ CONFIG_QEMU_HARDWARE=y
> # CONFIG_THREADS is not set
> # CONFIG_RELOCATE_INIT is not set
> # CONFIG_BOOTMENU is not set
> -# CONFIG_BOOTORDER is not set
> +CONFIG_BOOTORDER=y
> # CONFIG_ENTRY_EXTRASTACK is not set
> CONFIG_MALLOC_UPPERMEMORY=y
> CONFIG_ROM_SIZE=0
> @@ -92,7 +92,7 @@ CONFIG_VGA_EXTRA_STACK_SIZE=512
> #
> # Debugging
> #
> -CONFIG_DEBUG_LEVEL=-1
> +CONFIG_DEBUG_LEVEL=1
> CONFIG_DEBUG_SERIAL=y
> CONFIG_DEBUG_SERIAL_PORT=0x3f8
> CONFIG_DEBUG_IO=n
> Index: patches/patch-src_boot_c
> ===
> RCS file: patches/patch-src_boot_c
> diff -N patches/patch-src_boot_c
> --- patches/patch-src_boot_c11 Jul 2018 09:09:46 -1.1
> +++ /dev/null1 Jan 1970 00:00:00 -
> @@ -1,43 +0,0 @@
>  src/boot.c.origTue Jul 10 14:52:11 2018
> -+++ src/boot.cTue Jul 10 14:53:18 2018
> -@@ -659,7 +659,7 @@ boot_cdrom(struct drive_s *drive)
> - {
> - if (! CONFIG_CDROM_BOOT)
> - return;
> --printf("Booting from DVD/CD...\n");
> -+dprintf(1, "Booting from DVD/CD...\n");
> - 
> - int status = cdrom_boot(drive);
> - if (status) {
> -@@ -685,7 +685,7 @@ boot_cbfs(struct cbfs_file *file)
> - {
> - if (!CONFIG_COREBOOT_FLASH)
> - return;
> --printf("Booting from CBFS...\n");
> -+dprintf(1, "Booting from CBFS...\n");
> - cbfs_run_payload(file);
> - }
> - 
> -@@ -693,7 +693,7 @@ boot_cbfs(struct cbfs_file *file)
> - static void
> - boot_rom(u32 vector)
> - {
> --printf("Booting from ROM...\n");
> -+dprintf(1, "Booting from ROM...\n");
> - struct segoff_s so;
> - so.segoff = vector;
> - call_boot_entry(so, 0);
> -@@ -733,11 +733,11 @@ do_boot(int seq_nr)
> - struct bev_s *ie = [seq_nr];
> - switch (ie->type) {
> - case IPL_TYPE_FLOPPY:
> --printf("Booting from Floppy...\n");
> -+dprintf(1, "Booting from Floppy...\n");
> - boot_disk(0x00, CheckFloppySig);
> - break;
> - case IPL_TYPE_HARDDISK:
> --printf("Booting from Hard Disk...\n");
> -+dprintf(1, "Booting from Hard Disk...\n");
> - boot_disk(0x80, 1);
> - break;
> - case IPL_TYPE_CDROM:
> Index: patches/patch-src_fw_paravirt_c
> ===
> RCS file: /cvs/ports/sysutils/firmware/vmm/patches/patch-src_fw_paravirt_c,v
> retrieving revision 1.2
> diff -u -p -r1.2 patch-src_fw_paravirt_c
> --- patches/patch-src_fw_paravirt_c26 Apr 2018 12:23:32 -1.2
> +++ patches/patch-src_fw_paravirt_c9 Dec 2018 10:55:37 -
> @@ -1,18 +1,27 @@
> $OpenBSD: patch-src_fw_paravirt_c,v 1.2 2018/04/26 12:23:32 sthen Exp $
> 
> +Don't use 'rep insb' to read IO ports, vmm does not support that yet.
> Allow detection of >4GB RAM. Normally seabios only allows this with the
> qemu config device which VMM doesn't have.
> 
> Index: src/fw/paravirt.c
> --- src/fw/paravirt.c.orig
> +++ src/fw/paravirt.c
> -@@ -500,6 +500,18 @@ qemu_cfg_e820(void)
> - dprintf(1, "RamSizeOver4G: 0x%016llx [cmos]\n", RamSizeOver4G);
> +@@ -257,7 +257,9 @@ qemu_cfg_read(void *buf, int len)
> + if (qemu_cfg_dma_enabled()) {
> + qemu_cfg_dma_transfer(buf, len, 

CVS: cvs.openbsd.org: ports

[Reyk Floeter]

CVSROOT:/cvs
Module name:ports
Changes by: r...@cvs.openbsd.org2018/08/22 03:43:15

Modified files:
geo/openbsd-developers: Makefile 
geo/openbsd-developers/files: OpenBSD 

Log message:
I moved from Hannover to Zurich.  Gruezi miteinand!

OK tb@

CVS: cvs.openbsd.org: ports

[Reyk Floeter]

CVSROOT:/cvs
Module name:ports
Changes by: r...@cvs.openbsd.org2018/07/24 05:37:49

Modified files:
devel/cvs2gitdump: Makefile distinfo 

Log message:
Update cvs2gitdump to the latest version

OK sthen@

update devel/cvs2gitdump

[Reyk Floeter]

Hi,

I noticed that cvs2gitdump is old.  The update is easy as the latest
version is mostly about whitespace fixes; but updating the port saves
others from looking at python code to compare if there were any
relevant changes ;)

OK?

Reyk

Index: devel/cvs2gitdump/Makefile
===
RCS file: /cvs/ports/devel/cvs2gitdump/Makefile,v
retrieving revision 1.3
diff -u -p -u -p -r1.3 Makefile
--- devel/cvs2gitdump/Makefile  4 Oct 2016 16:01:29 -   1.3
+++ devel/cvs2gitdump/Makefile  24 Jul 2018 10:19:11 -
@@ -2,10 +2,10 @@
 
 COMMENT =  import cvs tree into git or subversion
 
-DISTNAME = cvs2gitdump-20160815
+DISTNAME = cvs2gitdump-20170517
 GH_ACCOUNT =   yasuoka
 GH_PROJECT =   cvs2gitdump
-GH_COMMIT =831c8e0fc69c04fa760b3cc3efb2e4523f9199d3
+GH_COMMIT =68bfed7274ce97e215fa1a4502feb0e8e5c54c8c
 
 CATEGORIES =   devel
 
Index: devel/cvs2gitdump/distinfo
===
RCS file: /cvs/ports/devel/cvs2gitdump/distinfo,v
retrieving revision 1.4
diff -u -p -u -p -r1.4 distinfo
--- devel/cvs2gitdump/distinfo  6 May 2017 15:10:17 -   1.4
+++ devel/cvs2gitdump/distinfo  24 Jul 2018 10:19:11 -
@@ -1,2 +1,2 @@
-SHA256 (cvs2gitdump-20160815-831c8e0f.tar.gz) = 
YiJAcPhre4im9Pjo8nAicSuh7Xw2OvuwO3Fknucdhb8=
-SIZE (cvs2gitdump-20160815-831c8e0f.tar.gz) = 9566
+SHA256 (cvs2gitdump-20170517-68bfed72.tar.gz) = 
MGxptKshmrOPXTLJtFUmj3CrNJU+98iytk8cYEi483s=
+SIZE (cvs2gitdump-20170517-68bfed72.tar.gz) = 9875

CVS: cvs.openbsd.org: ports

[Reyk Floeter]

CVSROOT:/cvs
Module name:ports
Changes by: r...@cvs.openbsd.org2018/07/11 03:09:46

Modified files:
sysutils/firmware/vmm: Makefile 
sysutils/firmware/vmm/files: config 
sysutils/firmware/vmm/patches: patch-Makefile 
Added files:
sysutils/firmware/vmm/patches: patch-sgabios_sgabios_S 
   patch-src_boot_c 
   patch-src_config_h 
   patch-src_fw_smbios_c 

Log message:
Disable BIOS debug messages and turn on SMBIOS.

This includes the following changes:

- Disable debugging in SeaBIOS except of a single version line:
SeaBIOS (version 1.11.0p0-OpenBSD-vmm)

- Turn off all debug messages of the SGABIOS payload
(1.11.0p0-OpenBSD-vmm is all we need to know, it is documented in the
firmware package that it is included in vmm-firmware).

- Enable SMBIOS: this now gives a BIOS version string in the dmesg and
hw.vendor + hw.product sysctl values (you can also query the SMBIOS
with the dmidecode package).  Please note that SeaBIOS sets all SMBIOS
strings to "Bochs Bochs" by default, we include patch-src_fw_smbios_c
to print OpenBSD, VMM, SeaBIOS, and 1.11.0p0-OpenBSD-vmm as the BIOS
version accordingly.

OK sthen@ mlarkin@

CVS: cvs.openbsd.org: ports

[Reyk Floeter]

CVSROOT:/cvs
Module name:ports
Changes by: r...@cvs.openbsd.org2018/05/16 06:25:48

Modified files:
sysutils   : Makefile 

Log message:
Enable sysutils/cloud-agent

Re: REMOVE: sysutils/waagent

[Reyk Floeter]

On Wed, May 16, 2018 at 08:43:36AM +0100, Stuart Henderson wrote:
> On 2018/05/15 23:51, Reyk Floeter wrote:
> > Hi,
> > 
> > I don't maintain sysutils/waagent anymore and I'd like to remove it.
> > 
> > I'm still running OpenBSD in Azure but my cloud-agent (see previous
> > mail NEW: sysutils/cloud-agent) allowed to replace it with a simpler,
> > cleaner, safer tool.  I don't think that too many (any?) other users
> > depend on the waagent port and they can still install it from source.
> > 
> > OK to remove waagent?
> > 
> > Reyk
> > 
> 
> Yes.
> 
> It'll need an entry in $obsolete_reason in devel/quirks/files/Quirks.pm,
> the numbers are detailed below the list, for this probably 6 ("no longer
> useful"), or maybe add a new one to direct people at cloud-agent instead
> (see #9 for an example).
> 

I would say #6 is best;  adding a specific message is not worth of it.

Reyk

CVS: cvs.openbsd.org: ports

[Reyk Floeter]

CVSROOT:/cvs
Module name:ports
Changes by: r...@cvs.openbsd.org2018/05/16 05:58:32

Log message:
Import cloud-agent, a simple cloud init for Azure, AWS, OpenStack etc.

This is a simple OpenBSD-specific agent that handles provisioning and
cloud initialization on clouds such as Microsoft Azure, Amazon AWS,
Apache CloudStack, or OpenStack.

OK sthen@

Status:

Vendor Tag: reyk
Release Tags:   reyk_20180516

N ports/sysutils/cloud-agent/Makefile
N ports/sysutils/cloud-agent/distinfo
N ports/sysutils/cloud-agent/pkg/DESCR
N ports/sysutils/cloud-agent/pkg/PLIST

No conflicts created by this import

Re: NEW: sysutils/cloud-agent

[Reyk Floeter]

On Wed, May 16, 2018 at 11:33:40AM +0100, Stuart Henderson wrote:
> On 2018/05/16 12:27, Reyk Floeter wrote:
> > On Wed, May 16, 2018 at 11:11:31AM +0100, Stuart Henderson wrote:
> > > On 2018/05/16 11:55, Reyk Floeter wrote:
> > > > Hi,
> > > > 
> > > > On Tue, May 15, 2018 at 11:46:45PM +0200, Reyk Floeter wrote:
> > > > > attached is a new port, sysutils/cloud-agent.  I wrote this tool
> > > > > myself and you can find it on https://github.com/reyk/cloud-agent.
> > > > 
> > > > New version of the port, with the following changes:
> > > > 
> > > > - Added expat to WANTLIB (pointed out by Rafael)
> > > > - Uploaded my own release tarball (pointed out by Stuart,
> > > > see https://www.conserver.com/pipermail/users/2018-March/msg5.html)
> > > > 
> > > > new pkg/DESCR:
> > > > ---
> > > > This is a simple OpenBSD-specific agent that handles provisioning and
> > > > cloud initialization on clouds such as Microsoft Azure, Amazon AWS,
> > > > Apache CloudStack, or OpenStack.
> > > > ---
> > > > 
> > > > OK?
> > > > 
> > > > Reyk
> > > 
> > > Seems ssl isn't actually linked (I'm not sure what purpose DPADD servers
> > > in agent/Makefile?)  So I think WANTLIB should be "c crypto tls expat".
> > > 
> > > Otherwise OK.
> > > 
> > 
> > Well, it does link with libssl, libcrypto, and libtls.  It works
> > because libtls is linked against libssl and libcrypto and our linker
> > is smart enough to handle those inter-library dependencies.
> > 
> > But it doesn't work with static linking (make LDSTATIC=-static) and
> > LDADD should really be "LDADD+= -lexpat -ltls -lssl -lcrypto".
> > 
> > I will fix it in the next upstream version of cloud-agent but I think
> > that the current port with "WANTLIB= c tls ssl crypto expat" is fine.
> > 
> > Unless there are issues on non-amd64/i386 platforms?  I don't have
> > access to any of them at the moment.
> > 
> > $ grep LDADD Makefile
> > LDADD+= -lexpat -ltls
> > $ ldd obj/cloud-agent
> > obj/cloud-agent:
> > StartEnd  Type  Open Ref GrpRef Name
> > 189a1b40 189a1b60e000 exe   10   0  
> > obj/cloud-agent
> > 189d01b2d000 189d01d58000 rlib  01   0  
> > /usr/lib/libexpat.so.12.0
> > 189c8a57e000 189c8a78e000 rlib  01   0  
> > /usr/lib/libtls.so.17.1
> > 189c8bb95000 189c8be77000 rlib  01   0  
> > /usr/lib/libc.so.92.3
> > 189c9ea0f000 189c9edef000 rlib  02   0  
> > /usr/lib/libcrypto.so.43.1
> > 189d0d3bd000 189d0d611000 rlib  01   0  
> > /usr/lib/libssl.so.45.1
> > 189d0820 189d0820 ld.so 01   0  
> > /usr/libexec/ld.so
> > 
> > Reyk
> > 
> 
> ldd shows too much information for ports WANTLIB purposes, look at
> readelf -d or objdump -p:
> 
> $ readelf -d libexec/cloud-agent bin/cms
> 
> File: libexec/cloud-agent
> 
> Dynamic section at offset 0xcb18 contains 18 entries:
>   TagType Name/Value
>  0x0001 (NEEDED) Shared library: [libexpat.so.12.0]
>  0x0001 (NEEDED) Shared library: [libtls.so.17.1]
>  0x0001 (NEEDED) Shared library: [libc.so.92.3]
>  0x0004 (HASH)   0x107a20
>  0x0005 (STRTAB) 0x108908
>  0x0006 (SYMTAB) 0x107d98
>  0x000a (STRSZ)  1009 (bytes)
>  0x000b (SYMENT) 24 (bytes)
>  0x0015 (DEBUG)  0x0
>  0x0003 (PLTGOT) 0x20cc98
>  0x0002 (PLTRELSZ)   2376 (bytes)
>  0x0014 (PLTREL) RELA
>  0x0017 (JMPREL) 0x108e08
>  0x0007 (RELA)   0x108d00
>  0x0008 (RELASZ) 264 (bytes)
>  0x0009 (RELAENT)24 (bytes)
>  0x6ff9 (RELACOUNT)  5
>  0x (NULL)   0x0
> 
> File: bin/cms
> 
> Dynamic section at offset 0x25208 contains 17 entries:
>   TagType Name/Value
>  0x0001 (NEEDED) Shared library: [libcrypto.so.43.1]
>  0x0001 (NEEDED) Shared librar

Re: NEW: sysutils/cloud-agent

[Reyk Floeter]

On Wed, May 16, 2018 at 11:11:31AM +0100, Stuart Henderson wrote:
> On 2018/05/16 11:55, Reyk Floeter wrote:
> > Hi,
> > 
> > On Tue, May 15, 2018 at 11:46:45PM +0200, Reyk Floeter wrote:
> > > attached is a new port, sysutils/cloud-agent.  I wrote this tool
> > > myself and you can find it on https://github.com/reyk/cloud-agent.
> > 
> > New version of the port, with the following changes:
> > 
> > - Added expat to WANTLIB (pointed out by Rafael)
> > - Uploaded my own release tarball (pointed out by Stuart,
> > see https://www.conserver.com/pipermail/users/2018-March/msg5.html)
> > 
> > new pkg/DESCR:
> > ---
> > This is a simple OpenBSD-specific agent that handles provisioning and
> > cloud initialization on clouds such as Microsoft Azure, Amazon AWS,
> > Apache CloudStack, or OpenStack.
> > ---
> > 
> > OK?
> > 
> > Reyk
> 
> Seems ssl isn't actually linked (I'm not sure what purpose DPADD servers
> in agent/Makefile?)  So I think WANTLIB should be "c crypto tls expat".
> 
> Otherwise OK.
> 

Well, it does link with libssl, libcrypto, and libtls.  It works
because libtls is linked against libssl and libcrypto and our linker
is smart enough to handle those inter-library dependencies.

But it doesn't work with static linking (make LDSTATIC=-static) and
LDADD should really be "LDADD+= -lexpat -ltls -lssl -lcrypto".

I will fix it in the next upstream version of cloud-agent but I think
that the current port with "WANTLIB= c tls ssl crypto expat" is fine.

Unless there are issues on non-amd64/i386 platforms?  I don't have
access to any of them at the moment.

$ grep LDADD Makefile
LDADD+= -lexpat -ltls
$ ldd obj/cloud-agent
obj/cloud-agent:
StartEnd  Type  Open Ref GrpRef Name
189a1b40 189a1b60e000 exe   10   0  obj/cloud-agent
189d01b2d000 189d01d58000 rlib  01   0  
/usr/lib/libexpat.so.12.0
189c8a57e000 189c8a78e000 rlib  01   0  
/usr/lib/libtls.so.17.1
189c8bb95000 189c8be77000 rlib  01   0  
/usr/lib/libc.so.92.3
189c9ea0f000 189c9edef000 rlib  02   0  
/usr/lib/libcrypto.so.43.1
189d0d3bd000 189d0d611000 rlib  01   0  
/usr/lib/libssl.so.45.1
189d0820 189d0820 ld.so 01   0  
/usr/libexec/ld.so

Reyk

Re: NEW: sysutils/cloud-agent

[Reyk Floeter]

Hi,

On Tue, May 15, 2018 at 11:46:45PM +0200, Reyk Floeter wrote:
> attached is a new port, sysutils/cloud-agent.  I wrote this tool
> myself and you can find it on https://github.com/reyk/cloud-agent.

New version of the port, with the following changes:

- Added expat to WANTLIB (pointed out by Rafael)
- Uploaded my own release tarball (pointed out by Stuart,
see https://www.conserver.com/pipermail/users/2018-March/msg5.html)

new pkg/DESCR:
---
This is a simple OpenBSD-specific agent that handles provisioning and
cloud initialization on clouds such as Microsoft Azure, Amazon AWS,
Apache CloudStack, or OpenStack.
---

OK?

Reyk


port-cloud-agent-0.6-c.tar.gz
Description: application/tar-gz

Re: NEW: sysutils/cloud-agent

[Reyk Floeter]

On Tue, May 15, 2018 at 11:46:45PM +0200, Reyk Floeter wrote:
> Hi,
> 
> attached is a new port, sysutils/cloud-agent.  I wrote this tool
> myself and you can find it on https://github.com/reyk/cloud-agent.
> 
> There are many cloud-init-like scripts for OpenBSD but the agent is
> multicloud, pledged, and includes support for Azure's weird method.
> Having a package would make deployment even easier.
> 
> ---
> pkg/DESCR:
> This is a simple OpenBSD-specific agent that handles provisioning and
> cloud initialization on clouds such as Microsoft Azure, Amazon AWS, or
> OpenStack.  It is an alternative to sysutils/waagent on Azure.
> ---
> 
> Tested on Azure, AWS, OpenStack/VMware, Exoscale, vmd (with meta-data).
> 
> OK?
> 
> Reyk

And now with the attachment ...



port-cloud-agent-0.6.tar.gz
Description: application/tar-gz

REMOVE: sysutils/waagent

[Reyk Floeter]

Hi,

I don't maintain sysutils/waagent anymore and I'd like to remove it.

I'm still running OpenBSD in Azure but my cloud-agent (see previous
mail NEW: sysutils/cloud-agent) allowed to replace it with a simpler,
cleaner, safer tool.  I don't think that too many (any?) other users
depend on the waagent port and they can still install it from source.

OK to remove waagent?

Reyk

NEW: sysutils/cloud-agent

[Reyk Floeter]

Hi,

attached is a new port, sysutils/cloud-agent.  I wrote this tool
myself and you can find it on https://github.com/reyk/cloud-agent.

There are many cloud-init-like scripts for OpenBSD but the agent is
multicloud, pledged, and includes support for Azure's weird method.
Having a package would make deployment even easier.

---
pkg/DESCR:
This is a simple OpenBSD-specific agent that handles provisioning and
cloud initialization on clouds such as Microsoft Azure, Amazon AWS, or
OpenStack.  It is an alternative to sysutils/waagent on Azure.
---

Tested on Azure, AWS, OpenStack/VMware, Exoscale, vmd (with meta-data).

OK?

Reyk

newer boost?

[Reyk Floeter]

Hi,

I've only found the recent "devel/boost vs. clang" mail, so I have a
question: is there any attempt to update boost to the latest version
or is there a known problem with it?

I see that the port has been fixed for clang but boost 1.58.0 is quite
old while the latest stable version is 1.64.0.  I tried to compile
solidity but it fails with all kinds of boost-related errors and at
least a few of them have been fixed in newer releases.

Reyk

CVS: cvs.openbsd.org: ports

[Reyk Floeter]

CVSROOT:/cvs
Module name:ports
Changes by: r...@cvs.openbsd.org2017/06/23 06:46:45

Modified files:
sysutils   : Makefile 

Log message:
add waagent, OK sthen@

CVS: cvs.openbsd.org: ports

[Reyk Floeter]

CVSROOT:/cvs
Module name:ports
Changes by: r...@cvs.openbsd.org2017/06/23 06:37:09

Log message:
The Microsoft Azure Linux Agent (waagent) manages Linux & BSD
provisioning, and VM interaction with the Azure Fabric Controller.

OpenBSD is supported by upstream since version 2.2.13.

OK sthen@

Status:

Vendor Tag: reyk
Release Tags:   reyk_20170623

N ports/sysutils/waagent/Makefile
N ports/sysutils/waagent/distinfo
N ports/sysutils/waagent/pkg/DESCR
N ports/sysutils/waagent/pkg/PLIST
N ports/sysutils/waagent/pkg/waagent.rc
N ports/sysutils/waagent/patches/patch-azurelinuxagent_common_conf_py
N ports/sysutils/waagent/patches/patch-azurelinuxagent_ga_update_py
N ports/sysutils/waagent/patches/patch-config_openbsd_waagent_conf
N ports/sysutils/waagent/patches/patch-config_waagent_conf
N 
ports/sysutils/waagent/patches/patch-azurelinuxagent_common_osutil_openbsd_py

No conflicts created by this import

Re: New: sysutils/waagent

[Reyk Floeter]

Hi,

On Thu, Jun 22, 2017 at 03:03:25PM +0100, Stuart Henderson wrote:
> On 2017/06/22 13:52, Reyk Floeter wrote:
> > Hi,
> > 
> > we need an "agent" to run VMs in Azure; this is a port of WALinuxAgent.
> > 
> > Unlike other clouds, it is not enough to run a simple "cloud-init"
> > script to provision VMs.  The latest version 2.2.13 of WALinuxAgent
> > already supports OpenBSD, they merged my patch, and it would be
> > desirable to have it as a package/port in OpenBSD.
> > 
> > pkg/DESCR:
> > The Microsoft Azure Linux Agent (waagent) manages Linux & BSD
> > provisioning, and VM interaction with the Azure Fabric Controller.
> > 
> > Full description:
> > The Microsoft Azure Linux Agent (waagent) manages Linux & BSD
> > provisioning, and VM interaction with the Azure Fabric Controller. It
> > provides the following functionality for Linux and BSD IaaS
> > deployments:
> > 
> >   * Image Provisioning
> > - Creation of a user account
> > - Configuring SSH authentication types
> > - Deployment of SSH public keys and key pairs
> > - Setting the host name
> > - Publishing the host name to the platform DNS
> > - Reporting SSH host key fingerprint to the platform
> > - Resource Disk Management
> > - Formatting and mounting the resource disk
> > - Configuring swap space
> > 
> > [...skipped Linux-specific features...]
> > 
> > It includes local patches to _disable_ "extensions" by default
> > (see also https://github.com/Azure/WALinuxAgent/pull/782):
> > 
> >   * VM Extension
> > - Inject component authored by Microsoft and Partners into Linux VM 
> > (IaaS)
> >   to enable software and configuration automation
> > - VM Extension reference implementation on 
> > https://github.com/Azure/azure-linux-extensions
> > 
> > 
> > Notes:
> > 
> >   * DISCLAIMER: I haven't done a port for years and I seriously lack ports
> > knowsledge with my total 9 ports commits since 2004.
> >   * With some port help from jsg@, especially for the GH_* part.
> >   * I try to find time to create another, minimal agent without Python...
> > I've already done this for a different platform.
> > 
> > Reyk
> 
> I agree it seems useful to have in packages.
> 
> /etc paths coming from ports/packages are meant to be subst'ed
> with ${SYSCONFDIR} as technically it is allowed to override this
> during build. For this it would affect the path to waagent.conf
> but not things like /etc/ssh, /etc/master.passwd, /etc/doas.conf
> which are from base.
> 
> I think it should be enough to add this to __init in OPENBSDOSUtil ..
> 
> self.agent_conf_file_path = '${SYSCONFDIR}/waagent.conf'
> 
> .. and do something like
> 
> pre-configure:
>   ${SUBST_CMD} ${WRKSRC/azurelinuxagent/common/osutil/openbsd.py
> 
> .. and use ${SYSCONFDIR} instead of hardcoded /etc in the @sample line
> in PLIST.
> 

Done, your example works just fine.

> Please also add a comment near the OpenSSL RUN_DEPENDS to say
> way (IIUC it's because LibreSSL has removed CMS support).
> 

That is exactly the case, I added the comment.

The agent uses "openssl cms" to decrypt messages containing the
certificates (ssh public keys) from the "wire" server in the Azure
fabric - there is no way to avoid it with the current protocol.

We actually ported "cms" as a stand-alone binary that links with
LibreSSL, but this is a big ugly hack (as it needs to include many
internal structures from libcrypto) - hard to tell what is worse:
installing openssl or using the cms-libressl hack for a single purpose ;)

> By convention the first commit of a new port (or an updated port)
> is done without a REVISION marker, it doesn't really matter though.
> 

OK, I removed the REVISION marker.

I attached an updated tarball.

Thanks for the feedback!
Reyk


port-waagent-2.2.13-2.tar.gz
Description: application/tar-gz

New: sysutils/waagent

[Reyk Floeter]

Hi,

we need an "agent" to run VMs in Azure; this is a port of WALinuxAgent.

Unlike other clouds, it is not enough to run a simple "cloud-init"
script to provision VMs.  The latest version 2.2.13 of WALinuxAgent
already supports OpenBSD, they merged my patch, and it would be
desirable to have it as a package/port in OpenBSD.

pkg/DESCR:
The Microsoft Azure Linux Agent (waagent) manages Linux & BSD
provisioning, and VM interaction with the Azure Fabric Controller.

Full description:
The Microsoft Azure Linux Agent (waagent) manages Linux & BSD
provisioning, and VM interaction with the Azure Fabric Controller. It
provides the following functionality for Linux and BSD IaaS
deployments:

  * Image Provisioning
- Creation of a user account
- Configuring SSH authentication types
- Deployment of SSH public keys and key pairs
- Setting the host name
- Publishing the host name to the platform DNS
- Reporting SSH host key fingerprint to the platform
- Resource Disk Management
- Formatting and mounting the resource disk
- Configuring swap space

[...skipped Linux-specific features...]

It includes local patches to _disable_ "extensions" by default
(see also https://github.com/Azure/WALinuxAgent/pull/782):

  * VM Extension
- Inject component authored by Microsoft and Partners into Linux VM (IaaS)
  to enable software and configuration automation
- VM Extension reference implementation on 
https://github.com/Azure/azure-linux-extensions


Notes:

  * DISCLAIMER: I haven't done a port for years and I seriously lack ports
knowsledge with my total 9 ports commits since 2004.
  * With some port help from jsg@, especially for the GH_* part.
  * I try to find time to create another, minimal agent without Python...
I've already done this for a different platform.

Reyk


port-waagent-2.2.13.tar.gz
Description: application/tar-gz

Re: [new] aws cli tools

[Reyk Floeter]

On Wed, Jan 06, 2016 at 02:18:09PM +0100, Antoine Jacoutot wrote:
> Hi.
> 
> This tarball contains the AWS cli tools to manage your cloud resources.
> It comes with several new dependencies.
> 
> I'd like to get it in soon and maybe polish a few things after import.
> And then I will bring the EC2 tools and the aws shell in.
> 
> Please test, comment, ok...
> 
> $ aws --version
> aws-cli/1.9.16 Python/2.7.11 OpenBSD/5.9 botocore/1.3.16
> 

Nice!

$ aws ec2 get-console-output --instance-id i-c7cf777b   
i-c7cf777b  +2176664+267272+0+647168 [72+576648+383917]=0xa6eb00
entry point at 0x1001000 [7205c766, 3404, 24448b12, 60a304]
[ using 961280 bytes of bsd ELF symbol table ]
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2016 OpenBSD. All rights reserved.  http://www.OpenBSD.org

OpenBSD 5.9-beta (GENERIC.MP-xen) #50: Wed Jan  6 15:03:16 CET 2016
r...@esdenera.com:/usr/src/sys/arch/amd64/compile/GENERIC.MP-xen
real mem = 1056964608 (1008MB)
avail mem = 1020788736 (973MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xeb01f (11 entries)
bios0: vendor Xen version "4.2.amazon" date 12/07/2015
bios0: Xen HVM domU
acpi0 at bios0: rev 2
acpi0: sleep states S3 S4 S5
acpi0: tables DSDT FACP APIC HPET WAET SSDT SSDT
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 11, 48 pins
ioapic0: misconfigured as apic 0, remapped to apid 1
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Xeon(R) CPU E5-2676 v3 @ 2.40GHz, 2400.39 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,LONG,LAHF,ABM,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 100MHz
acpihpet0 at acpi0: 6250 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpicpu0 at acpi0: C1(@1 halt!)
pvbus0 at mainbus0: Xen 4.2
xen0 at pvbus0
xen0: hypercall page at va 0x81002000 pa 0x1002000
xen0: version 4.2.amazon
xen0: features 705
xen0: shared info page at va 0x800ef000 pa 0x3f6fe000
xen0: registered callback IDT vector 112
xen0: grant table frames allocated 32/32
xen0: xenstore event channel 3
xen0: xenstore ring at va 0x800014ad8000 pa 0xfeffc000
xen0: xenstore interrupt established for port 3
"vfb" at xen0: device/vfb/0 not configured
"vbd" at xen0: device/vbd/768 not configured
xen0: xenstore request 2 "device/vif/0/type" error ENOENT
xnf0 at xen0: event channel 5, address 06:c0:fd:39:93:7f
"console" at xen0: device/console/0 not configured
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02
pcib0 at pci0 dev 1 function 0 "Intel 82371SB ISA" rev 0x00
pciide0 at pci0 dev 1 function 1 "Intel 82371SB IDE" rev 0x00: DMA, channel 0 
wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0: 
wd0: 16-sector PIO, LBA48, 1024MB, 2097152 sectors
wd0(pciide0:0:0): using PIO mode 0, DMA mode 2
pciide0: channel 1 disabled (no drives)
piixpm0 at pci0 dev 1 function 3 "Intel 82371AB Power" rev 0x01: SMBus disabled
vga1 at pci0 dev 2 function 0 "Cirrus Logic CL-GD5446" rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
xspd0 at pci0 dev 3 function 0 "XenSource Platform Device" rev 0x01
isa0 at pcib0
isadma0 at isa0
fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
fd0 at fdc0 drive 0: density unknown
fd1 at fdc0 drive 1: density unknown
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com0: console
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pms0 at pckbc0 (aux slot)
wsmouse0 at pms0 mux 0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
vmm at mainbus0 not configured
nvram: invalid checksum
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
scsibus2 at softraid0: 256 targets
root on wd0a (eeacdbd148573cfa.a) swap on wd0b dump on wd0b
clock: unknown CMOS layout
Automatic boot in progress: starting file system checks.
/dev/wd0a (eeacdbd148573cfa.a): file system is clean; not checking
setting tty flags
pf enabled
starting network
DHCPDISCOVER on xnf0 - interval 3
DHCPOFFER from 172.31.16.1 (06:bc:14:46:67:74)
DHCPREQUEST on xnf0 to 255.255.255.255
DHCPACK from 172.31.16.1 (06:bc:14:46:67:74)
bound to 172.31.17.41 -- renewal in 1800 seconds.
openssl: generating isakmpd/iked RSA keys... done.
ssh-keygen: generating new host keys: RSA DSA ECDSA ED25519 
starting early daemons: syslogd pflogd ntpd.
starting RPC daemons:.
savecore: no core dump

Re: SSL_CTX_use_certificate_chain fallout

[Reyk Floeter]

Am 30.09.2014 um 15:39 schrieb Christian Weisgerber na...@mips.inka.de:

 Joel Sing:
 
 === www/apache-httpd-openbsd
 === www/apache-httpd
 
 Is this the only ports fallout?
 
 Yes.
 

So what about patching these two apache ports instead of LibreSSL?

It is a valid addition to the library and LibreSSL has to handle such API 
additions at some point.

Reyk

CVS: cvs.openbsd.org: ports

[Reyk Floeter]

CVSROOT:/cvs
Module name:ports
Changes by: r...@cvs.openbsd.org2013/05/30 11:39:49

Modified files:
geo/openbsd-developers: Makefile 
geo/openbsd-developers/files: OpenBSD 

Log message:
I moved several times since I entered my coordinates here.
landry@ reminded me to update the entry.