Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Stefan Sperling]

On Fri, Dec 11, 2015 at 11:58:17AM +0100, Thijs van Dijk wrote:
> On 11 December 2015 at 05:51, Andy Bradford 
> wrote:
> 
> > If one wants privacy on a website then more is required than just HTTPS.
> >
> 
> Right. *I* just want a reasonable (256-bit) guarantee that the signify keys
> on my screen are the ones the OpenBSD authors intended me to see.
> 
> I currently just assume they are correct because it'd be enormously complex
> to spoof the entire OpenBSD distribution, but I souldn't have to rely on
> "security through effort involved".

I would consider signify keys printed on CDs and copied across several
web sites safer than trusting the hundreds of CA certs shipped with a
standard web browser.

Instead of verifying signify keys you'd now have to keep a copy of
openbsd.org's SSL cert fingerprint and keep track of that as it changes.
And it won't conventiently change in lock step with OpenBSD's release
schedule like signify keys do.

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Tati Chevron]

On Fri, Dec 11, 2015 at 11:58:17AM +0100, Thijs van Dijk wrote:

On 11 December 2015 at 05:51, Andy Bradford 
wrote:


If one wants privacy on a website then more is required than just HTTPS.



Right. *I* just want a reasonable (256-bit) guarantee that the signify keys
on my screen are the ones the OpenBSD authors intended me to see.


The official CD set contains the signify keys for that release and the
next one.  Once you have a known good copy of one set, you can always obtain
future ones securely.

You don't even need to use the CD set to install, just as a way of obtaining
the signify keys with a high degree of confidence.

--
Tati Chevron
Perl and FORTRAN specialist.
SWABSIT development and migration department.
http://www.swabsit.com

Re: NOT POSSIBLE: Fully encrypted system with keydisk

[Tati Chevron]

On Thu, Dec 10, 2015 at 07:33:57PM -0500, trondd wrote:

On Thu, December 10, 2015 6:35 pm, Stefan Wollny wrote:

YES: I did 'disklabel -E sd0' and 'disklabel -E sd1' accordingly,

setting every partition to type RAID

How many partitions are you making on sd0?  For FDE, typically you make
one partition of type RAID filling the disk (or your desired OpenBSD area)
and all the other partitions are created inside of it.  How are you
partitioning the drives?


YES: I did 'bioctl -C force -c C -l /dev/sd0d -k /dev/sd1d softraid0'


Why force?  Why partition d?  Again, how are you partitioning your drives?


Why wouldn't a single partition d spanning the whole drive be the logical
choice for a disk that is going to be a used entirely as a softraid crypto
volume?

The RAID partition is not a root filesystem in itself, so if you are
implying that it should be a single partition a spanning the whole drive,
I disagree.

--
Tati Chevron
Perl and FORTRAN specialist.
SWABSIT development and migration department.
http://www.swabsit.com

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Constantine A. Murenin]

On 8 December 2015 at 19:26, Anthony J. Bentley  wrote:
> Giancarlo Razzolini writes:
>> One of the main benefits of the TLS wouldn't only be to render
>> impossible for anyone to know which pages you're accessing on the site,
>> but also the fact that we would get a little more security getting the
>> SSH fingerprints for the anoncvs servers. Having them in clear text as
>> they are today, isn't very secure.
>
> Another attack currently possible against www.openbsd.org is changing
> the https://openbsdstore.com links to http://openbsdstore.com, and
> running sslstrip on that. Or the PayPal links...

For real!  And yet another attack currently possible against
www.openbsd.org is being able to view the web-site from any OpenBSD
release, even the early ones that did include lynx in base
(http://mdoc.su/OpenBSD-2.3/lynx.1), yet are surely missing not only
TLSv1.2 (if not OpenSSL in the first place!), but the requisite CA
entries in their corresponding cert.pem file as well (that is, if such
file was even present).

And if you're in Kazakhstan, it's also possible to view
www.openbsd.org without any issues or security warnings, and will
continue being so even after 2016-01-01 when the new telecommunication
directive takes force.  (Or was the feature to ignore invalid
certificates already added to lynx nowadays?)

And another one is a global web-site defacing if the certificate
signing request infrastructure, with a client that is designed to run
on your web-server with the web-server privileges by LetsEncrypt, and
must execute at least once every 3 months (if not more often, as their
plan is to decrease cert validity to be even shorter than 3 months)
turns out to contain an exploitable vulnerability.  Wait, that's one
not possible!  (At least not yet!)

C.

Re: NOT POSSIBLE: Fully encrypted system with keydisk

[Stefan Sperling]

On Fri, Dec 11, 2015 at 09:53:48AM +0100, Alexander Hall wrote:
> On December 11, 2015 1:27:52 AM GMT+01:00, Stuart Henderson 
>  wrote:
> >On 2015-12-10, Stefan Wollny  wrote:
> 
> >> YES: I did 'bioctl -C force -c C -l /dev/sd0d -k /dev/sd1d softraid0'
> >> YES: I did again 'sh ./MAKEDEV all' to catch the newly created sd2
> >
> >In the above step, you have run yourself out of space on the
> >ramdisk by creating a load of device nodes that you don't have
> >space for and don't need.
> 
> Indeed. In particular, you tend to run out of inodes.
> 
> /Alexander 

Yes. That step should be: sh ./MAKEDEV sd2

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Thijs van Dijk]

On 11 December 2015 at 05:51, Andy Bradford 
wrote:

> If one wants privacy on a website then more is required than just HTTPS.
>

Right. *I* just want a reasonable (256-bit) guarantee that the signify keys
on my screen are the ones the OpenBSD authors intended me to see.

I currently just assume they are correct because it'd be enormously complex
to spoof the entire OpenBSD distribution, but I souldn't have to rely on
"security through effort involved".

Remember the guy who tried to securely download PuTTY? He couldn't

.
Be snobbish all you want about using Windows and expecting any level
security, but having to give your SSH login info to an unauthenticated
binary from the internet because there is no other option is a pretty
serious problem, which could easily have been prevented by simply enabling
HTTPS.

-Thijs

Re: NOT POSSIBLE: Fully encrypted system with keydisk

[Tati Chevron]

On Thu, Dec 10, 2015 at 07:33:57PM -0500, trondd wrote:

On Thu, December 10, 2015 6:35 pm, Stefan Wollny wrote:

YES: I did 'disklabel -E sd0' and 'disklabel -E sd1' accordingly,

setting every partition to type RAID

How many partitions are you making on sd0?  For FDE, typically you make
one partition of type RAID filling the disk (or your desired OpenBSD area)
and all the other partitions are created inside of it.  How are you
partitioning the drives?


YES: I did 'bioctl -C force -c C -l /dev/sd0d -k /dev/sd1d softraid0'


Why force?  Why partition d?  Again, how are you partitioning your drives?


Why wouldn't a single partition d spanning the whole drive be the logical
choice for a disk that is going to be a used entirely as a softraid crypto
volume?

The RAID partition is not a root filesystem in itself, so if you are
implying that it should be a single partition a spanning the whole drive,
I disagree.

--
Tati Chevron
Perl and FORTRAN specialist.
SWABSIT development and migration department.
http://www.swabsit.com

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Anthony J. Bentley]

"Constantine A. Murenin" writes:
> On 8 December 2015 at 19:26, Anthony J. Bentley  wrote:
> > Giancarlo Razzolini writes:
> >> One of the main benefits of the TLS wouldn't only be to render
> >> impossible for anyone to know which pages you're accessing on the site,
> >> but also the fact that we would get a little more security getting the
> >> SSH fingerprints for the anoncvs servers. Having them in clear text as
> >> they are today, isn't very secure.
> >
> > Another attack currently possible against www.openbsd.org is changing
> > the https://openbsdstore.com links to http://openbsdstore.com, and
> > running sslstrip on that. Or the PayPal links...
> 
> For real!  And yet another attack currently possible against
> www.openbsd.org is being able to view the web-site from any OpenBSD
> release, even the early ones that did include lynx in base
> (http://mdoc.su/OpenBSD-2.3/lynx.1), yet are surely missing not only
> TLSv1.2 (if not OpenSSL in the first place!), but the requisite CA
> entries in their corresponding cert.pem file as well (that is, if such
> file was even present).

Why even bring up OpenBSD 2.3? Anyone running that 19 years after its
release has much bigger problems than not being able to connect to
www.openbsd.org.

> And if you're in Kazakhstan, it's also possible to view
> www.openbsd.org without any issues or security warnings, and will
> continue being so even after 2016-01-01 when the new telecommunication
> directive takes force.  (Or was the feature to ignore invalid
> certificates already added to lynx nowadays?)

I can't tell if you're saying it's a *good* thing that http provides no
notice that your connection is compromised. Are you serious?

Look, the whole CA model comes with a lot of baggage. Let's Encrypt has
elements of a new approach but is still tied to that way of thinking.
Talking on misc@ won't make www.openbsd.org more secure.

But you're defending telnet in 2015.

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Kamil Cholewiński]

> The official CD set contains the signify keys for that release and the
> next one.  Once you have a known good copy of one set, you can always obtain
> future ones securely.
>
> You don't even need to use the CD set to install, just as a way of obtaining
> the signify keys with a high degree of confidence.

This is the real thing bothering me. I don't even have a CD drive
available, and I was about to ask if it would be possible to get the
signify keys via paper mail in exchange for a donation. But both paper
and CDs can be intercepted and tampered with (with some effort).

> I currently just assume they are correct because it'd be enormously
> complex to spoof the entire OpenBSD distribution, but I souldn't have
> to rely on "security through effort involved".

Exactly, and this is a problem with the CDs too. There's currently no
way to securely bootstrap the chain of trust. HTTPS is a way to do that.

Yes, we would have to rely on third parties (CAs). It can be optional
(so that a text browser from an ancient unsupported release can still
access plain HTTP version fine). It can be just a single page like
keys.openbsd.org so that there are few extra computing resources used.
It doesn't have to be Let's Encrypt - heck, I'm willing to go to
RapidSSL or whoever and pay for it myself if someone can give me a CSR
and assist with domain validation.

K.

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Thijs van Dijk]

On 11 December 2015 at 12:28, Stefan Sperling  wrote:

> I would consider signify keys printed on CDs and copied across several
> web sites safer than trusting the hundreds of CA certs shipped with a
> standard web browser.


On 11 December 2015 at 12:35, Tati Chevron  wrote:

> The official CD set contains the signify keys for that release and the
> next one.  Once you have a known good copy of one set, you can always
> obtain
> future ones securely.


Both of you are missing my point, but it's entirely possible I didn't
articulate it properly.

I know I can trust the CD's; it's one of the main reasons I buy them with
every release.
I'm saying I shouldn't *have* to rely on snail-mailed physical media. We,
as a species, have thought of a solution to this problem long ago.

Sure that solution isn't perfect, but if I can guess at the list's
attitude, I'd say it's this:

>  "If we can't make it impossible to intercept traffic, we shouldn't
bother with making it merely fiendishly difficult."

which I think is unnecessarily fatalistic.


In either case, I'd be willing to put my money where my mouth is.
Whom do I contact about running a site mirror?

-Thijs

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Tati Chevron]

On Fri, Dec 11, 2015 at 12:48:19PM +0100, Thijs van Dijk wrote:

I'm saying I shouldn't *have* to rely on snail-mailed physical media. We,
as a species, have thought of a solution to this problem long ago.


I agree in principle that we shouldn't have to rely in physical media to
obtain the keys with a high degree of confidence.  Currently, though, it
is a good way.


Sure that solution isn't perfect, but if I can guess at the list's
attitude, I'd say it's this:


 "If we can't make it impossible to intercept traffic, we shouldn't

bother with making it merely fiendishly difficult."

which I think is unnecessarily fatalistic.


I think the attitude is more of priorities and the best way to expend
time and effort.

The OP was talking about https access to the entire www.openbsd.org site
whereas the discussion has now moved to obtaining the CVS tree and the
signify keys securely, which is a somewhat different issue.

My previous point was that once you have obtained ONE signify key,
you can obtain every future -release and verify it's integrity without
ever buying another CD.  You can't follow -current and be sure of the
integrity of what you are downloading.  Of course, if anybody did
tamper with a CVS checkout of the tree, it's quite possible that you
would notice when things didn't work as expected, or future patches
didn't apply, it would depend on the sophistication of the tampering.

My personal opinion is that https://www.openbsd.org would be rather
pointless, and lead people to a false sense of security, whereas
some kind of encryption and authentication for CVSync would be useful.

On the other hand, an increase in the general proportion of web traffic
that is encrypted does make mass surveilance more time consuming and
less practical.  Making www.openbsd.org available via https would not
contribute much at all to that, and would take resources away from
the project that could be used for other things.


In either case, I'd be willing to put my money where my mouth is.
Whom do I contact about running a site mirror?


Why would we trust your mirror?

--
Tati Chevron
Perl and FORTRAN specialist.
SWABSIT development and migration department.
http://www.swabsit.com

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Tati Chevron]

On Fri, Dec 11, 2015 at 12:58:38PM +0100, Kamil Cholewi??ski wrote:

This is the real thing bothering me. I don't even have a CD drive
available, and I was about to ask if it would be possible to get the
signify keys via paper mail in exchange for a donation.


The official CDs have the signify key physically printed on them.


But both paper
and CDs can be intercepted and tampered with (with some effort).


Well then you need to meet Theo in person and obtain the keys from him
directly.  Except, how would you know it was really Theo?


I currently just assume they are correct because it'd be enormously
complex to spoof the entire OpenBSD distribution, but I souldn't have
to rely on "security through effort involved".


Exactly, and this is a problem with the CDs too. There's currently no
way to securely bootstrap the chain of trust. HTTPS is a way to do that.


Would you really trust HTTPS more than a physical CD being mailed to
you???


Yes, we would have to rely on third parties (CAs). It can be optional
(so that a text browser from an ancient unsupported release can still
access plain HTTP version fine). It can be just a single page like
keys.openbsd.org so that there are few extra computing resources used.
It doesn't have to be Let's Encrypt - heck, I'm willing to go to
RapidSSL or whoever and pay for it myself if someone can give me a CSR
and assist with domain validation.


If you want to rely on third parties, I can send you a copy of the
signify keys, signed by my PGP key.  How would that help you at all?

--
Tati Chevron
Perl and FORTRAN specialist.
SWABSIT development and migration department.
http://www.swabsit.com

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Tati Chevron]

On Fri, Dec 11, 2015 at 04:37:39AM -0700, Anthony J. Bentley wrote:

Why even bring up OpenBSD 2.3? Anyone running that 19 years after its
release has much bigger problems than not being able to connect to
www.openbsd.org.


I must admit that since gopher://openbsd.org shut down, and tenex support
was removed from FTP, the overall user experience of OpenBSD has really
deteriorated...

--
Tati Chevron
Perl and FORTRAN specialist.
SWABSIT development and migration department.
http://www.swabsit.com

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Thijs van Dijk]

On 11 December 2015 at 13:10, Tati Chevron  wrote:

> In either case, I'd be willing to put my money where my mouth is.
>> Whom do I contact about running a site mirror?
>>
>
> Why would we trust your mirror?


Touché.

Re: I have problem compiling libgdamm

[Lampshade]

It was the root cause of problem.
When I downloaded release tarball instead of something from
git.gnome.org it compiled successfully.
Thanks for help.

Od: "Callum Davies" 
Do: "Lampshade" ;
Wysłane: 17:31 Niedziela 2015-12-06
Temat: Re: I have problem compiling libgdamm

> I'm running current amd64.  There's no need to run autogen.sh if you
> are using a release tarball of libgdamm.

Re: NOT POSSIBLE: Fully encrypted system with keydisk

[Stefan Sperling]

On Fri, Dec 11, 2015 at 01:18:55PM +0100, Stefan Wollny wrote:
> OK - follow up problem: After the installation on /dev/sd3 (plus setting up 
> /dev/sd4 for /home) I did not reboot but run installboot(8) like so:
> # /usr/sbin/installboot sd3
> 
> This last produced an error message about /usr/mdec/biosboot missing.
> 
> Mind giving me an other hint on what I might have missed? I searched the man 
> pages but nothing obvious came to me. Has there been some recent changes?

In the bsd.rd ramdisk, the installed system's root disk (sd3a) is mounted
at /mnt, and the installed system's user partition is mounted at /mnt/usr.

So this should work: /mnt/usr/sbin/installboot -r /mnt sd3

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Giancarlo Razzolini]

Em 10-12-2015 20:03, Christian Weisgerber escreveu:
> The true elephant in the room is that I can't get the current OpenBSD
> source tree securely.  (Well, _I_ can if push comes to shove, but
> the general user community can't.)  CVSync?  No integrity or
> authenticity.  AnonCVS over SSH?  Nope, no integrity or authenticity
> because the mirror itself got the tree over CVSync.  Assuming you
> trust the mirror in the first place.

I agree with you. We don't want TLS to hide the fact that we are
accessing the openbsd site. We want TLS to get a little extra confidence
that what we are seeing on our screen is what the OpenBSD devs wanted us
to see. Someone mentioned signify keys also. Nowadays if I want to be
(kind of) sure I got everything right, I need to download the files from
different mirrors, using different internet connections, using vpn's and
tor, etc.

The TLS could be implemented on a non mandatory way, you don't need to
redirect HTTP connections to HTTPS ones. But it would be nice to have
the option, at least.

Cheers,
Giancarlo Razzolini

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Thijs van Dijk]

On 11 December 2015 at 14:16, Tati Chevron  wrote:

> But even if PKI were actively on fire at the moment (which it is not),
>> what's wrong with doing both?
>>
>
> Basically the gain verses the effort and resources expended.
>
> I agree that there is a value in distributing keys and source code in a way
> that makes tampering difficult or highly visible.
>
> I disagree that serving www.openbsd.org over https is a good way of doing
> that.


Fair enough.
Though I personally still think it'd be a good idea, I am just a stranger
on the internet and this is not a vote.

-Thijs

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Constantine A. Murenin]

On 11 December 2015 at 02:58, Thijs van Dijk  wrote:
> On 11 December 2015 at 05:51, Andy Bradford 
> wrote:
>
>> If one wants privacy on a website then more is required than just HTTPS.
>>
>
> Right. *I* just want a reasonable (256-bit) guarantee that the signify keys
> on my screen are the ones the OpenBSD authors intended me to see.
>
> I currently just assume they are correct because it'd be enormously complex
> to spoof the entire OpenBSD distribution, but I souldn't have to rely on
> "security through effort involved".
>
> Remember the guy who tried to securely download PuTTY? He couldn't
> 

And I couldn't access his web-site from an OpenBSD box:

% lynx -dump 
https://noncombatant.org/2014/03/03/downloading-software-safely-is-nearly-impossible/

Looking up noncombatant.org
Making HTTPS connection to noncombatant.org
SSL callback:unable to get local issuer certificate, preverify_ok=0, ssl_okay=0
Retrying connection without TLS.
Looking up noncombatant.org
Making HTTPS connection to noncombatant.org
Alert!: Unable to make secure connection to remote host.

lynx: Can't access startfile
https://noncombatant.org/2014/03/03/downloading-software-safely-is-nearly-impossible/
%

C.

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Tati Chevron]

On Fri, Dec 11, 2015 at 01:53:04PM +0100, Thijs van Dijk wrote:

On 11 December 2015 at 13:17, Tati Chevron  wrote:


Would you really trust HTTPS more than a physical CD being mailed to
you???



Yes.

Both provide some level of accountability, however with PKI you explicitly
trust a limited (though big) numer of third parties to do their job
properly, and in the case of a screwup, at least everyone involved is nice
enough to leave their name in the certificate chain. The same can't be said
for the hundreds of anonymous hands that handle my snail mail.


On the other hand, if somebody actually received a fake OpenBSD CD in
the mail, and it was discovered, it would be a huge news story within the
IT industry.  A bad download, much less so.

Some years ago, when the Linux kernel was managed with BitKeeper, somebody
tried to introduce malicious code into a CVS gateway.  It was quickly
discovered by Larry McVoy during normal integrity checks.  It was a news
story for a while then faded away.  Who remembers it now?  On the other hand,
physical interception, tampering and replacement of a disc set for a project
like OpenBSD would catch the interest of the IT industry, and conspiracy
theories would run wild.

It's usually relatively easy to hack into something.  It's much more difficult
to cover your tracks.


But even if PKI were actively on fire at the moment (which it is not),
what's wrong with doing both?


Basically the gain verses the effort and resources expended.

I agree that there is a value in distributing keys and source code in a way
that makes tampering difficult or highly visible.

I disagree that serving www.openbsd.org over https is a good way of doing
that.

--
Tati Chevron
Perl and FORTRAN specialist.
SWABSIT development and migration department.
http://www.swabsit.com

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Raul Miller]

On Fri, Dec 11, 2015 at 7:10 AM, Tati Chevron  wrote:
> Why would we trust your mirror?

A couple things to keep in mind here:

(1) Security can never be perfect.
(2) Security does not have to be perfect.

(That said... sometimes traditional computer security seems like
people are trying to put bank vault doors on picket fences. And, ok,
given the state of the internet, there's some validity to that
approach. But I imagine we should be thinking about other approaches,
also.)

Anyways, for distributions, you need good ways of detecting problems.
Then, when you find one, you will at least gain some information about
your threats.

So:

(1) shasums, and other signatures. The more the merrier, within
practical limits. They can be spoofed, but plausibly spoofing several
is difficult. You should expect attackers to want to hit easier
targets.

(2) out-of-band comparisons. This does not need to be frequent, but
needs to be happening. If people adopt rituals where they sometimes
download from websites, sometimes compare web site contents with cd
contents, and also sometimes check electronic copies of signatures
with paper copies, you will catch infections sooner or later. One of
the more important characteristics, here, is probably the time delays
in the comparisons.

(3) Have some ideas of what to do when you find a problem. Rewriting
or replacing or discarding the affected systems is one approach.
Involving people who have reason to care can be another approach. This
is where having a good audience can help - industry, politicians,
volunteer organizations, etc. all have an aspect where they try to
engage lots of people. If you are supporting them (don't worry too
much about the degree of support - it mostly doesn't matter) they'll
quite probably be happy to help when you need it (especially if they
can also see how to advance their own goals - which, ok, will
sometimes be a pain).

Anyways... there's plenty more nuances than this quick writeup. The
basic approach is to drive up the costs/effort required for
sophisticated and organized attackers while also catching the flaws
which will inevitably arise (through hardware failures if nothing
else, but school-age pranks are another plausible candidate for
problems).

I hope some of this helps,

-- 
Raul

P.S. the three biggest state-level threats are probably the three most
populated countries. China and India want to destroy some parts of
their populations while maintaining loyalty of their core population
(because they can't feed them all, but you can see this in the news,
for example in reports about rotting food, perhaps tons of it - people
are strange). The USA doesn't have the food issue and (because of its
structure) places a higher priority on popularity/loyalty, but is
under immense long-term pressure to fit in  (whatever that means). I'm
not sure what to do about any of that, but I think this point of view
does help understand what was happening with the NSA but also it's why
the whole "for the people" quip gets the emotional shadings that it
gets. I can't do much about this, but maybe someone else will have
some good ideas? And, of course, there's plenty of smaller countries
which have their own personality-driven issues, wars and malware
havens.

Re: NOT POSSIBLE: Fully encrypted system with keydisk

[Stefan Wollny]

> Gesendet: Freitag, 11. Dezember 2015 um 14:52 Uhr
> Von: "Stefan Sperling" 
> An: "Stefan Wollny" 
> Cc: misc@openbsd.org
> Betreff: Re: NOT POSSIBLE: Fully encrypted system with keydisk
>
> On Fri, Dec 11, 2015 at 01:18:55PM +0100, Stefan Wollny wrote:
> > OK - follow up problem: After the installation on /dev/sd3 (plus setting up 
> > /dev/sd4 for /home) I did not reboot but run installboot(8) like so:
> > # /usr/sbin/installboot sd3
> > 
> > This last produced an error message about /usr/mdec/biosboot missing.
> > 
> > Mind giving me an other hint on what I might have missed? I searched the 
> > man pages but nothing obvious came to me. Has there been some recent 
> > changes?
> 
> In the bsd.rd ramdisk, the installed system's root disk (sd3a) is mounted
> at /mnt, and the installed system's user partition is mounted at /mnt/usr.
> 
> So this should work: /mnt/usr/sbin/installboot -r /mnt sd3
> 
> 

Hi Stefan,

THX a lot for (again) helping me and the explanation.

I run the command like you adviced and no error message showed up.

So far, so good - unfortunatelly the system still does not boot after the 
'reboot'. Still stops at the manufacturers splash screen not recognizing any 
storage device to boot from.

Any other idea? Could it be that this machine's particular BIOS needs an 'a' 
partition on sd0 to find the device? As the system is unusable at present and I 
need to disassemble the SSDs anyway to get them wiped in order to proceed with 
the next install I will give this a try.

Best,
STEFAN

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Thijs van Dijk]

On 11 December 2015 at 13:17, Tati Chevron  wrote:

> Would you really trust HTTPS more than a physical CD being mailed to
> you???


Yes.

Both provide some level of accountability, however with PKI you explicitly
trust a limited (though big) numer of third parties to do their job
properly, and in the case of a screwup, at least everyone involved is nice
enough to leave their name in the certificate chain. The same can't be said
for the hundreds of anonymous hands that handle my snail mail.

But even if PKI were actively on fire at the moment (which it is not),
what's wrong with doing both?

-Thijs

Re: NOT POSSIBLE: Fully encrypted system with keydisk

[Stefan Wollny]

> Gesendet: Freitag, 11. Dezember 2015 um 11:33 Uhr
> Von: "Stefan Sperling" 
> An: "Alexander Hall" 
> Cc: "Stuart Henderson" , misc@openbsd.org
> Betreff: Re: NOT POSSIBLE: Fully encrypted system with keydisk
>
> On Fri, Dec 11, 2015 at 09:53:48AM +0100, Alexander Hall wrote:
> > On December 11, 2015 1:27:52 AM GMT+01:00, Stuart Henderson 
> >  wrote:
> > >On 2015-12-10, Stefan Wollny  wrote:
> > 
> > >> YES: I did 'bioctl -C force -c C -l /dev/sd0d -k /dev/sd1d softraid0'
> > >> YES: I did again 'sh ./MAKEDEV all' to catch the newly created sd2
> > >
> > >In the above step, you have run yourself out of space on the
> > >ramdisk by creating a load of device nodes that you don't have
> > >space for and don't need.
> > 
> > Indeed. In particular, you tend to run out of inodes.
> > 
> > /Alexander 
> 
> Yes. That step should be: sh ./MAKEDEV sd2
> 

@Alexander, Stefan & Stuart:

I can confirm that this was the cause for the error message. Doing it as you 
advised enabled me to install amd64-current, yet some step is still missing as 
afer the reboot the system does not come up (stops at the splash screen not 
entering any boot operation).

A few words on my use case: From my customers I get sensible personal data on 
their customers (not only name/address, but job related information, income 
statements, ratings, etc.). Loosing the laptop when traveling would be painful 
but loosing the confidentiality would really hit me.

My setup: The laptop has two SSDs - a big one for '/home' and a smaller one 
(mSata) for the system (plus some spare).

The system-SSD (=sd0) has one partiion 'd' which gets unlocked by the keydisk's 
'd' partition (=> sd3)
The /home-SDD (=sd1) has one partition 'e' which gets unlocked by the keydisk's 
'e' partition (=> sd4)
On the keydisk (=sd2) there are some more partitions for keys and storage:
   'f' to unlock a backup-disk which I use onsite.
   'g' and 'h' for future use to unlock other devices (like e.g. USB devices).
   'i' an additional RAID partition for other sensible stuff (e.g. passwords 
for clients' systems which should be accessible in case of emergency from an 
unencrypted OpenBSD-box as well.

@stuart: dd fails with "file system ist full \ dd: /dev/rsd3c: No space left on 
device"

@trondd: Not having an 'a' partition on one of the three devices seemed to be 
helpful to memorize that this is not a 'normal' partition. No real technical 
reason otherwise.

OK - follow up problem: After the installation on /dev/sd3 (plus setting up 
/dev/sd4 for /home) I did not reboot but run installboot(8) like so:
# /usr/sbin/installboot sd3

This last produced an error message about /usr/mdec/biosboot missing.

Mind giving me an other hint on what I might have missed? I searched the man 
pages but nothing obvious came to me. Has there been some recent changes?

TIA.

Best,
STEFAN


BTW: A dmesg from an unencrypted install can be found here:
http://marc.info/?l=openbsd-misc=144956819405937=2

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Tati Chevron]

On Fri, Dec 11, 2015 at 01:28:04PM +0100, Kamil Cholewi??ski wrote:

The official CDs have the signify key physically printed on them.


You press a new CD, print a new cover, etc.


...and intercept the package being delivered to you?

Yes, it's possible, but somebody who had the resources to go to that
extreme, and a motive to single you out as a target, would presumably
have other ways to invade your privacy and integrity open to them.


If you want to rely on third parties, I can send you a copy of the
signify keys, signed by my PGP key.  How would that help you at all?


Sounds reasonable to me.


In what way does this help?

] -BEGIN PGP SIGNED MESSAGE-
] Hash: SHA1
] 
] untrusted comment: openbsd 5.5 base public key

] RWRGy8gxk9N9314J0gh9U02lA7s8i6ITajJiNgxQOndvXvM5ZPX+nQ9h
] untrusted comment: openbsd 5.5 firmware public key
] RWTdVOhdk5qyNktv0iGV6OpaVfogGxTYc1bbkaUhFlExmclYvpJR/opO
] untrusted comment: openbsd 5.5 packages public key
] RWQQC1M9dhm/tja/ktitJs/QVI1kGTQr7W7jtUmdZ4uTp+4yZJ6RRHb5
] untrusted comment: openbsd 5.6 base public key
] RWR0EANmo9nqhpPbPUZDIBcRtrVcRwQxZ8UKGWY8Ui4RHi229KFL84wV
] untrusted comment: openbsd 5.6 firmware public key
] RWT4e3jpYgSeLYs62aDsUkcvHR7+so5S/Fz/++B859j61rfNVcQTRxMw
] untrusted comment: openbsd 5.6 packages public key
] RWSPEf7Vpp2j0PTDG+eLs5L700nlqBFzEcSmHuv3ypVUEOYwso+UucXb
] untrusted comment: openbsd 5.7 base public key
] RWSvUZXnw9gUb70PdeSNnpSmodCyIPJEGN1wWr+6Time1eP7KiWJ5eAM
] untrusted comment: OpenBSD 5.7 firmware public key
] RWSuRBL44FVkb2QuvtlwOJmzS9UJtbKZd7GEYcol8HPXu4On/Ct1LoZr
] untrusted comment: openbsd 5.7 packages public key
] RWTJ1iHLn/zcvJJSbxJIEU9ChlfAlU16XoLLxmxciliOFWfTLyOv0vQs
] untrusted comment: openbsd 5.8 base public key
] RWQNNZXtC/MqP3Eiu+6FBz/qrxiWQwDhd+9Yljzp62UP4KzFmmvzVk60
] untrusted comment: OpenBSD 5.8 firmware public key
] RWTpkvg4fhJCDx9yL4bUCou/vtAecPVTfcaaGESQeBruwX/qHToMvWh6
] untrusted comment: OpenBSD 5.8 packages public key
] RWRlkI2aFHvL/XGqD+lFerD/xUi/jnAXKwdFQwZDekYwDrEPSpSWgpI9
] untrusted comment: openbsd 5.9 base public key
] RWQJVNompF3pwfIqbg+5sxfpxmZMa3tTBaW4qbUhWje/H/M7glrA6oVn
] untrusted comment: OpenBSD 5.9 firmware public key
] RWSdmaNkytzh6BApmPSNSDLNg26ZaXlY8g/879UvLdo3rjbsby76Eda1
] untrusted comment: OpenBSD 5.9 packages public key
] RWSLRYDCTJeWLIScncqwGuXK6JVXDcIyRT0q+0m30MXXG4W2xWS4NZBP
] -BEGIN PGP SIGNATURE-
] Version: GnuPG v1
] 
] iQIcBAEBAgAGBQJWasZfAAoJELBdwBmbGNHy2gMP/1ESt/E8kDS3CtODAyehvheH

] 5j0cEXBTnaVLFeu7jmGDbVIiukLBbjqJ3eQiwmwnBt3uSC0P/OyrHPlEsKc8rWqs
] dPejCdZbfPpwtBMOn4P33dblDwog7qfTGU1Qu0GO9XWmEovO4iBUYb0Nuc7nipQX
] fPyHtZZGNqvBiAGMU9i2YDzwn2tYW6gxiU0nB2SnT3acuJximw6/YrVENREQD4DD
] EekXcx8wYxBU+y3JE1fj90s1n3qXQm9s3B/Mm5/X8MIXZbi6W7dWnrIcrzDLDvyg
] ZV/4UC/90NcfUn0EKG+su8r1XuXszYDspOPz7qKPbx+X/aYCbwAlEx7ajVVj60kr
] yiuFk9yhPb7cFlR3EmuABY3P8u6N7KbeWinaXBy6dOxMYJDZgztVAcqIw72qhuNF
] NNtCY727EXlbhgF+adujDvyTFy2U2/13/vllbtOl9qaN/mYlUm1iVFdIMfLd0TGe
] Ts6AIazNZdbQxsUnglzpjhJqyNaoK73SoqwwawBDvT1TpU0T6weIdrQWWaYBjngr
] fd0xaR73GffvLO5gqnFdbikw6OGizGrGQ/YIN4354WoUzpmAXtXv8cajKVwKbP3F
] SnVzgRgPqQJDCQY3gqJ+cIHBQsL3yNTiWtq/gIYeK1W+Wm7yXKn+wKbngcyifoiG
] GnfSlG7cNb0cpB+pRJTr
] =Pzev
] -END PGP SIGNATURE-

--
Tati Chevron
Perl and FORTRAN specialist.
SWABSIT development and migration department.
http://www.swabsit.com

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Thijs van Dijk]

On 11 December 2015 at 13:51, Tati Chevron  wrote:

> ...and intercept the package being delivered to you?
>
> Yes, it's possible, but somebody who had the resources to go to that
> extreme, and a motive to single you out as a target, would presumably
> have other ways to invade your privacy and integrity open to them.
>

There you have it.
Security through effort involved. We don't need to make it fiendishly
difficult because we can't make it impossible.

-Thijs

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Constantine A. Murenin]

On 11 December 2015 at 05:37, Anthony J. Bentley  wrote:
> "Constantine A. Murenin" writes:
>> On 8 December 2015 at 19:26, Anthony J. Bentley  wrote:
>> > Giancarlo Razzolini writes:
>> >> One of the main benefits of the TLS wouldn't only be to render
>> >> impossible for anyone to know which pages you're accessing on the site,
>> >> but also the fact that we would get a little more security getting the
>> >> SSH fingerprints for the anoncvs servers. Having them in clear text as
>> >> they are today, isn't very secure.
>> >
>> > Another attack currently possible against www.openbsd.org is changing
>> > the https://openbsdstore.com links to http://openbsdstore.com, and
>> > running sslstrip on that. Or the PayPal links...
>>
>> For real!  And yet another attack currently possible against
>> www.openbsd.org is being able to view the web-site from any OpenBSD
>> release, even the early ones that did include lynx in base
>> (http://mdoc.su/OpenBSD-2.3/lynx.1), yet are surely missing not only
>> TLSv1.2 (if not OpenSSL in the first place!), but the requisite CA
>> entries in their corresponding cert.pem file as well (that is, if such
>> file was even present).
>
> Why even bring up OpenBSD 2.3? Anyone running that 19 years after its
> release has much bigger problems than not being able to connect to
> www.openbsd.org.

Not really.  It just works.  And there's always time to upgrade to a
newer OpenBSD release, since those continue to be served through http
without any issues.

>
>> And if you're in Kazakhstan, it's also possible to view
>> www.openbsd.org without any issues or security warnings, and will
>> continue being so even after 2016-01-01 when the new telecommunication
>> directive takes force.  (Or was the feature to ignore invalid
>> certificates already added to lynx nowadays?)
>
> I can't tell if you're saying it's a *good* thing that http provides no
> notice that your connection is compromised. Are you serious?

But http connections aren't compromised.  They're just monitored
passively.  (And it's all public data, and, as mentioned, even with
https, the hostnames would still have leaked.)

Since it's impossible to do the same with https, they have to be MitM'ed.

>
> Look, the whole CA model comes with a lot of baggage. Let's Encrypt has
> elements of a new approach but is still tied to that way of thinking.
> Talking on misc@ won't make www.openbsd.org more secure.
>
> But you're defending telnet in 2015.

No.  If you look closely at what Theo has said, especially around
pledge(2), telnet has more problems that just lack of encryption.
Kinda like HTTPS has few-too-many downfalls and bad policies other
than the availability of encryption.

C.

Re: Wifi Configuration | Realtek RTL8191SE

[Luiz Moraes]

Hi Stefan,
I already downloaded from http://firmware.openbsd.org/firmware/5.8/ the
firmwares *rtwn*, *rsu and* u*rtwn *and installed them all with *fw_update*,
later i restarted the laptop but the status on *dmesg *is the same.

I really would like to can keep OpenBSD as the main OS, but maybe i'll
have to get FreeBSD to use the *ndisgen (*Is the ndiswrapper for FreeBSD
and DragonflyBSD).
Can i get the *ndisgen *from FreeBSD and run on OpenBSD? (I woulnd like
to change it, but if the OpenBSD doesnt give me options i'll have to find a
way to keep me with it)




Luiz Diego Fernandes de Moraes


2015-12-11 14:11 GMT-02:00 Stefan Sperling :

> On Fri, Dec 11, 2015 at 01:38:24PM -0200, Luiz Moraes wrote:
> > Hi Everyone,
> > Im a Linux user (Slackware) and now i decided to try OpenBSD as my
> main
> > OS on my laptop, the only thing that i couldn't solve is to make my Wifi
> > card works on OpenBSD.
> >  It's a Realtek RTL8191SE PCI. I tried to compile Linux Driver with
> no
> > success and there is no ndiswrapper substitute on OpenBSD. How can i
> solve?
>
> New code needs to be written specifically for OpenBSD to support your
> device.
> The driver which may eventually support your card is rtwn(4).

Pictures are "blurred" in certain cases after snapshot upgrade (radeonrdrm related?)

[Alexis de BRUYN]

Hi Everybody,

After upgraded from snapshots/amd64 12/09/2015 (previous was 
12/04/2015), Puffy is blurred on xdm login screen (like [1]).


Puffy (/etc/X11/xdm/pixmaps/OpenBSD_15bpp.xpm) displayed in feh is fine 
[2], while in eog is blurred [1].


Pictures/thumbnails displayed and all icon buttons in/of Thunderbird, 
Firefox [3], Libreoffice, Evince (some texts too if zoomed)...


In Chromium [4], Gajim and Minitube, all is displayed fine.

After this upgraded I also have another issue [5]: 
radeon_ring_test_lockup / radeon_sa_bo_manager_fini *ERROR*


Today's snapshot sets and packages upgrade doesn't correct the problem.

(fresh dmesg and Xorg.0.log below)

Thanks for your help,

[1]: http://www.de-bruyn.fr/puffy_bad.png
[2]: http://www.de-bruyn.fr/puffy_good.png
[3]: http://www.de-bruyn.fr/firefox_bad.png
[4]: http://www.de-bruyn.fr/chromium_good.png
[5]: http://marc.info/?l=openbsd-tech=144984166819347=2

$ dmesg
OpenBSD 5.8-current (GENERIC.MP) #1737: Thu Dec 10 23:29:07 MST 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 34306285568 (32717MB)
avail mem = 33262448640 (31721MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb510 (78 entries)
bios0: vendor American Megatrends Inc. version "1.12" date 05/14/2013
bios0: Shuttle Inc. SZ77
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT ASF! MCFG SLIC HPET SSDT SSDT SSDT
acpi0: wakeup devices P0P1(S4) USB1(S3) USB2(S3) USB3(S3) USB4(S3) 
USB5(S3) USB6(S3) USB7(S3) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) 
RP03(S4) PXSX(S4) RP04(S4) [...]

acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz, 3492.52 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT

cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz, 3492.07 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT

cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz, 3492.07 MHz
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT

cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz, 3492.07 MHz
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT

cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 0, core 3, package 0
cpu4 at mainbus0: apid 1 (application processor)
cpu4: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz, 3492.07 MHz
cpu4: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT

cpu4: 256KB 64b/line 8-way L2 cache
cpu4: smt 1, core 0, package 0
cpu5 at mainbus0: apid 3 (application processor)
cpu5: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz, 3492.07 MHz
cpu5: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT

cpu5: 256KB 64b/line 8-way L2 cache
cpu5: smt 1, core 1, package 0
cpu6 at mainbus0: apid 5 (application processor)
cpu6: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz, 3492.07 MHz
cpu6: 

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[nanaya]

Hi,

On Fri, Dec 11, 2015, at 23:39, Raul Miller wrote:
> On Fri, Dec 11, 2015 at 7:10 AM, Tati Chevron 
> wrote:
> > Why would we trust your mirror?
> 
> A couple things to keep in mind here:
> 
> (1) Security can never be perfect.
> (2) Security does not have to be perfect.
> 


And here's a kind reminder that default openbsd base install already
included a bunch of root certificates[1] which hopefully means those
listed in this file are deemed trustworthy to a certain level.

[1]
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libcrypto/cert.pem?rev=1.7

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Giancarlo Razzolini]

Em 11-12-2015 09:28, Stefan Sperling escreveu:
> I would consider signify keys printed on CDs and copied across several
> web sites safer than trusting the hundreds of CA certs shipped with a
> standard web browser.

Didn't we just established that with HPKP you can disregard the CA
completely? At least if you trust your fist access to the site. But I
think this thread followed its course, lets move on.

Cheers,
Giancarlo Razzolini

Re: NOT POSSIBLE: Fully encrypted system with keydisk

[Tati Chevron]

On Fri, Dec 11, 2015 at 03:30:04PM +0100, Stefan Wollny wrote:

Gesendet: Freitag, 11. Dezember 2015 um 14:52 Uhr
Von: "Stefan Sperling" 
An: "Stefan Wollny" 
Cc: misc@openbsd.org
Betreff: Re: NOT POSSIBLE: Fully encrypted system with keydisk

On Fri, Dec 11, 2015 at 01:18:55PM +0100, Stefan Wollny wrote:
> OK - follow up problem: After the installation on /dev/sd3 (plus setting up 
/dev/sd4 for /home) I did not reboot but run installboot(8) like so:
> # /usr/sbin/installboot sd3
>
> This last produced an error message about /usr/mdec/biosboot missing.
>
> Mind giving me an other hint on what I might have missed? I searched the man 
pages but nothing obvious came to me. Has there been some recent changes?

In the bsd.rd ramdisk, the installed system's root disk (sd3a) is mounted
at /mnt, and the installed system's user partition is mounted at /mnt/usr.

So this should work: /mnt/usr/sbin/installboot -r /mnt sd3




Hi Stefan,

THX a lot for (again) helping me and the explanation.

I run the command like you adviced and no error message showed up.

So far, so good - unfortunatelly the system still does not boot after the 
'reboot'. Still stops at the manufacturers splash screen not recognizing any 
storage device to boot from.

Any other idea? Could it be that this machine's particular BIOS needs an 'a' 
partition on sd0 to find the device? As the system is unusable at present and I 
need to disassemble the SSDs anyway to get them wiped in order to proceed with 
the next install I will give this a try.


The layout of the paritions within the disklabel shouldn't be of any
concern to the BIOS.

There has been discusson on the list previously about buggy BIOSes that
lock up if a disk is connected that doesn't contain a standard MBR and
partition table.  However, since you indicate that you can install and
boot OpenBSD on a non-encrypted volume on the same disks, that doesn't
seem like the problem.

--
Tati Chevron
Perl and FORTRAN specialist.
SWABSIT development and migration department.
http://www.swabsit.com

Re: NOT POSSIBLE: Fully encrypted system with keydisk

[Stuart Henderson]

On 2015-12-11, Stefan Wollny  wrote:
> @stuart: dd fails with "file system ist full \ dd: /dev/rsd3c: No space left 
> on device"

Guessing that you didn't create the sd3 device nodes before doing the dd.
At this point you probably have a file (not device node) named /dev/rsd3c.

Re: Wifi Configuration | Realtek RTL8191SE

[Stefan Sperling]

On Fri, Dec 11, 2015 at 01:38:24PM -0200, Luiz Moraes wrote:
> Hi Everyone,
> Im a Linux user (Slackware) and now i decided to try OpenBSD as my main
> OS on my laptop, the only thing that i couldn't solve is to make my Wifi
> card works on OpenBSD.
>  It's a Realtek RTL8191SE PCI. I tried to compile Linux Driver with no
> success and there is no ndiswrapper substitute on OpenBSD. How can i solve?

New code needs to be written specifically for OpenBSD to support your device.
The driver which may eventually support your card is rtwn(4).

Re: ld.so behavior with $ORIGIN

[Aurélien Vallée]

Just found I can set LD_DEBUG to see the full translation process of ld.so.
This seems to confirm what I've seen in the source: ld.so uses cwd
instead of process file location for $ORIGIN interpolation.

$ mkdir -p /tmp/dummy/working/directory

$ cd /tmp/dummy/working/directory

$ which python
/home/avallee/bin/python

$ readelf -d $(which python)
0x0001 (NEEDED) Shared library: [libpython2.7.so.1.0]
0x000f (RPATH) Library rpath: [$ORIGIN/../lib]
0x6ffb (FLAGS_1) Flags: ORIGIN

$ LD_DEBUG=1 python
rtld loading: 'python'
...
orig_path $ORIGIN/../lib
new_path /tmp/dummy/working/directory/../lib


$ LD_DEBUG=1 $(which python)
...
orig_path $ORIGIN/../lib
new_path /home/avallee/bin/../lib


On Fri, Dec 11, 2015 at 5:04 PM, Aurélien Vallée
 wrote:
> Hello,
>
> I have troubles understanding the interpretation of $ORIGIN on
> OpenBSD. I'm switching to OpenBSD from Linux, so I may be biased in my
> assumptions.
>
> I built a program (python in this example) with the following ld
parameters:
>
> -Wl,origin,z
> -Wl,rpath,'$ORIGIN/../lib'
>
> I can then check that the proper attributes were set on the binary:
>
> $ readelf -d python
> ...
> 0x0001 (NEEDED) Shared library: [libpython2.7.so.1.0]
> ...
> 0x000f (RPATH) Library rpath: [$ORIGIN/../lib]
> ...
> 0x6ffb (FLAGS_1) Flags: ORIGIN
>
> On the filesystem, everything is also correct, say I have:
>
> - The python binary located in ~/bin/python
> - The python library located in ~/lib/libpython2.7.so.1.0
>
> Now if I run python using its absolute or relative path, everything
> works fine. However when I add python to my $PATH, and call it by name
> (just "python"), the loader complains it cannot find
> libpython2.7.so.1.0.
>
> e.g. with python in my $PATH:
>
> $ python
> python: can't load library 'libpython2.7.so.1.0'
>
> That won't work, while:
>
> $ $(which python)
>
> or
>
> $ ~/bin/python
>
> or
>
> $ /home/.../bin/python
>
> These will work.
>
> Strangely, if I cd to the directory where python is located, then I
> can issue just "python" and it will work. e.g:
>
> $ cd ~/bin
> $ python
>
> It seems to me that $ORIGIN is interpreted as a relative path from the
> elf file when calling it with an absolute path, or relative to the
> path of the caller when using $PATH.
>
> I did not expect this behavior, as "man ld.so" states:
>
>> When resolving dependencies for the loaded objects, ld-elf.so.1 may be
>> allowed to translate dynamic token strings in rpath and soname by
setting
>> -z origin option of the static linker ld(1).  The following strings
are
>> recognized now:
>> $ORIGIN Translated to the full path of the loaded object.
>
> Am I doing something wrong here, or is expected behavior?
>
> I've spent some time digging libexec/ld.so/resolve.c for an
> explanation (I'm on -current snapshots from Dec 3 2015, last week).
> It's not an easy lecture for a newcomer, so please forgive me if what
> I say below is complete garbage.
>
> Here is what I found:
>
> 1) My elf binary is loaded and ends up in _dl_finalize_object()
>
> 2) My binary has RPATH and FLAGS_1 to ORIGIN, so _dl_origin_subst() is
called
> if (object->dyn.rpath) {
>   object->rpath = _dl_split_path(object->dyn.rpath);
> if ((object->obj_flags & DF_1_ORIGIN) && _dl_trust)
>   _dl_origin_subst(object);
> }
>
> 3) _dl_origin_subst() retrieves the original path of the elf object,
> and applies $ORIGIN interpolation if necessary
> if (_dl_origin_path(object, origin_path) != 0)
>   return;
>
> /* perform path substitutions on each segment of rpath */
> for (pp = object->rpath; *pp != NULL; pp++) {
>   _dl_origin_subst_path(object, origin_path, pp);
> }
>
> 4) _dl_origin_subst_path() will use origin_path in case of $ORIGIN, so
> back to _dl_origin_path() to understand what is used.
> case SUBST_ORIGIN:
>   value = origin_path;
>   break;
>
> 5) _dl_origin_path() just uses _dl_realpath(_dl_dirname()) on the elf
object.
>
> 6) _dl_dirname() will return "." if the path provided does not contain a
'/'
>
> 7) _dl_realpath() will prepend the CWD to this.
>
> These last steps seems odd to me. Why is the CWD used here, when what
> we really want is the directory containing the binary of the currently
> running process (i.e. /proc/self/exe on linux).
> Just my guess, I don't really know what I'm talking about.
>
> Anyway, explanations  greatly appreciated! And again, please forgive
> me if all that is just me doing stupid things.



--
Aurélien Vallée
Phone +33 9 77 19 85 61

ld.so behavior with $ORIGIN

[Aurélien Vallée]

Hello,

I have troubles understanding the interpretation of $ORIGIN on
OpenBSD. I'm switching to OpenBSD from Linux, so I may be biased in my
assumptions.

I built a program (python in this example) with the following ld parameters:

-Wl,origin,z
-Wl,rpath,'$ORIGIN/../lib'

I can then check that the proper attributes were set on the binary:

$ readelf -d python
...
0x0001 (NEEDED) Shared library: [libpython2.7.so.1.0]
...
0x000f (RPATH) Library rpath: [$ORIGIN/../lib]
...
0x6ffb (FLAGS_1) Flags: ORIGIN

On the filesystem, everything is also correct, say I have:

- The python binary located in ~/bin/python
- The python library located in ~/lib/libpython2.7.so.1.0

Now if I run python using its absolute or relative path, everything
works fine. However when I add python to my $PATH, and call it by name
(just "python"), the loader complains it cannot find
libpython2.7.so.1.0.

e.g. with python in my $PATH:

$ python
python: can't load library 'libpython2.7.so.1.0'

That won't work, while:

$ $(which python)

or

$ ~/bin/python

or

$ /home/.../bin/python

These will work.

Strangely, if I cd to the directory where python is located, then I
can issue just "python" and it will work. e.g:

$ cd ~/bin
$ python

It seems to me that $ORIGIN is interpreted as a relative path from the
elf file when calling it with an absolute path, or relative to the
path of the caller when using $PATH.

I did not expect this behavior, as "man ld.so" states:

> When resolving dependencies for the loaded objects, ld-elf.so.1 may be
> allowed to translate dynamic token strings in rpath and soname by setting
> -z origin option of the static linker ld(1).  The following strings are
> recognized now:
> $ORIGIN Translated to the full path of the loaded object.

Am I doing something wrong here, or is expected behavior?

I've spent some time digging libexec/ld.so/resolve.c for an
explanation (I'm on -current snapshots from Dec 3 2015, last week).
It's not an easy lecture for a newcomer, so please forgive me if what
I say below is complete garbage.

Here is what I found:

1) My elf binary is loaded and ends up in _dl_finalize_object()

2) My binary has RPATH and FLAGS_1 to ORIGIN, so _dl_origin_subst() is called
if (object->dyn.rpath) {
  object->rpath = _dl_split_path(object->dyn.rpath);
if ((object->obj_flags & DF_1_ORIGIN) && _dl_trust)
  _dl_origin_subst(object);
}

3) _dl_origin_subst() retrieves the original path of the elf object,
and applies $ORIGIN interpolation if necessary
if (_dl_origin_path(object, origin_path) != 0)
  return;

/* perform path substitutions on each segment of rpath */
for (pp = object->rpath; *pp != NULL; pp++) {
  _dl_origin_subst_path(object, origin_path, pp);
}

4) _dl_origin_subst_path() will use origin_path in case of $ORIGIN, so
back to _dl_origin_path() to understand what is used.
case SUBST_ORIGIN:
  value = origin_path;
  break;

5) _dl_origin_path() just uses _dl_realpath(_dl_dirname()) on the elf object.

6) _dl_dirname() will return "." if the path provided does not contain a '/'

7) _dl_realpath() will prepend the CWD to this.

These last steps seems odd to me. Why is the CWD used here, when what
we really want is the directory containing the binary of the currently
running process (i.e. /proc/self/exe on linux).
Just my guess, I don't really know what I'm talking about.

Anyway, explanations  greatly appreciated! And again, please forgive
me if all that is just me doing stupid things.

Re: NOT POSSIBLE: Fully encrypted system with keydisk

[Stefan Sperling]

On Fri, Dec 11, 2015 at 03:30:04PM +0100, Stefan Wollny wrote:
> I run the command like you adviced and no error message showed up.
> 
> So far, so good - unfortunatelly the system still does not boot after the 
> 'reboot'. Still stops at the manufacturers splash screen not recognizing any 
> storage device to boot from.
> 
> Any other idea? Could it be that this machine's particular BIOS needs an 'a' 
> partition on sd0 to find the device? As the system is unusable at present and 
> I need to disassemble the SSDs anyway to get them wiped in order to proceed 
> with the next install I will give this a try.
> 
> Best,
> STEFAN

Hmm, that's odd. Could you show us the output of the following:

At the boot> prompt (if you can get there):

  machine diskinfo

In bsd.rd:

  fdisk sd0
  disklabel sd0

  fdisk sd3
  disklabel sd3

  bioctl softraid0

And also instalboot's verbose messages:

  /mnt/usr/sbin/installboot -v -r /mnt sd3

Another thing you could try to narrow down the problem is using
a passphrase instead of a key disk. Does that work?

Re: ld.so behavior with $ORIGIN

[Philip Guenther]

On Fri, Dec 11, 2015 at 10:18 AM, Theo de Raadt  wrote:
>> Just found I can set LD_DEBUG to see the full translation process of ld.so.
>> This seems to confirm what I've seen in the source: ld.so uses cwd
>> instead of process file location for $ORIGIN interpolation.
>  ^
>
> What is that?  Generally Unix has no way of doing this.  You can inspect
> your executable's __progname, which is cloned from argv at crt startup,
> but it may not contain an absolute path.  So what do you really mean here?

I'm not sure what Solaris does for this, but it looks like glibc on
Linux does readlink("/proc/self/exe") and if that fails and the
process trusts its environment** then it falls back to the
LD_ORIGIN_PATH environment variable.  $ORIGIN then expands to
dirname() of that.

What's desired, I think, is to base it on the resolved (ala
realpath()) value of the 'path' argument to execve().  At least that's
what the Solaris docs seem to imply.  Doesn't matter if that path
resolves to a different underlying file later: it's just going to be
used for the directory part anyway and it's ignored for privileged
processes.

I guess we could stick 'path' into an auxiliary vector value and have
ld.so do the realpath() call if $ORIGIN is used?  It would be that or
have the kernel store the whole path for the life of the process for
obtaining with sysctl().  Right now it only stores the last component
of the (resolved) original path in p_comm.


Philip Guenther


** i.e, not marked as 'secure', their sorta-similar-to-issetugid-but-not-really

Re: ld.so behavior with $ORIGIN

[Aurélien Vallée]

> glibc on
> Linux does readlink("/proc/self/exe") and if that fails and the
> process trusts its environment** then it falls back to the
> LD_ORIGIN_PATH environment variable.  $ORIGIN then expands to
> dirname() of that.

This is also what musl-libc do, except that it does not bother trying
something
else if that fails.

> It would be that or
> have the kernel store the whole path for the life of the process for
> obtaining with sysctl()

That would be great. ps and top would be able to display the path too,
pretty handy.

On Fri, Dec 11, 2015 at 9:04 PM, Philip Guenther  wrote:
> On Fri, Dec 11, 2015 at 10:18 AM, Theo de Raadt 
wrote:
>>> Just found I can set LD_DEBUG to see the full translation process of
ld.so.
>>> This seems to confirm what I've seen in the source: ld.so uses cwd
>>> instead of process file location for $ORIGIN interpolation.
>>  ^
>>
>> What is that?  Generally Unix has no way of doing this.  You can inspect
>> your executable's __progname, which is cloned from argv at crt startup,
>> but it may not contain an absolute path.  So what do you really mean here?
>
> I'm not sure what Solaris does for this, but it looks like glibc on
> Linux does readlink("/proc/self/exe") and if that fails and the
> process trusts its environment** then it falls back to the
> LD_ORIGIN_PATH environment variable.  $ORIGIN then expands to
> dirname() of that.
>
> What's desired, I think, is to base it on the resolved (ala
> realpath()) value of the 'path' argument to execve().  At least that's
> what the Solaris docs seem to imply.  Doesn't matter if that path
> resolves to a different underlying file later: it's just going to be
> used for the directory part anyway and it's ignored for privileged
> processes.
>
> I guess we could stick 'path' into an auxiliary vector value and have
> ld.so do the realpath() call if $ORIGIN is used?  It would be that or
> have the kernel store the whole path for the life of the process for
> obtaining with sysctl().  Right now it only stores the last component
> of the (resolved) original path in p_comm.
>
>
> Philip Guenther
>
>
> ** i.e, not marked as 'secure', their
sorta-similar-to-issetugid-but-not-really



--
Aurélien Vallée
Phone +33 9 77 19 85 61

Re: NOT POSSIBLE: Fully encrypted system with keydisk

[Mike Larkin]

On Sat, Dec 12, 2015 at 12:27:46AM +0100, Stefan Wollny wrote:
> Am 12/11/15 um 18:34 schrieb Stefan Sperling:
> >On Fri, Dec 11, 2015 at 05:44:36PM +0100, Stefan Wollny wrote:
> >>fdisk(25692): syscall 54 "ioctl"
> >>Abort trap
> >>>   disklabel sd3
> >>disklabel(3120): syscall 54 "ioctl"
> >>Abort trap
> >This is obviously not quite right.
> >It looks like you're using a snapshot with a pledge(2) bug.
> >
> >What snapshot are you booting? Please ensure that you're either
> >booting 5.8 or the latest snapshot and send a complete dmesg
> >if it is still failing.
> A couple of test iterations later ...
> 
> [TLDR: Still no reboot into an unencrypted system]
> 
> 
> These are the steps (annotated) I went through:
> 
> 
> 
> +++
> s
> 
> Prior to running bsr.rd check the chain of boot devices,
> has to be CD => sd0 => PXE
> 's' to choose "shell"
> fdisk sd0 => OK
> fdisk sd1 => not OK
> fdisk sd2 => not OK
> cd /dev
> sh ./MAKEDEV sd1
> sh ./MAKEDEV sd2
> cd /
> fdisk -iy sd0
> fdisk -iy sd1
> fdisk -iy sd2
> disklabel -E sd0
> entire HD: FS type RAID, partition 'd'
> disklabel -E sd1
> entire HD: FS type RAID, partition 'e'
> disklabel -E sd2
> partition 'd', size 1M, FS type RAID
> partition 'e', size 1M, FS type RAID
> partition 'f', size 1M, FS type RAID
> partition 'g', size 1M, FS type RAID
> partition 'h', size 1M, FS type RAID
> partition 'i', size , FS type 4.2BSD
> bioctl -c C -l /dev/sd0d -k /dev/sd2d softraid0
> bioctl -c C -l /dev/sd1e -k /dev/sd2e softraid0
> cd /dev
> sh ./MAKEDEV sd3
> sh ./MAKEDEV sd4
> cd /
> dd if=/dev/zero of=/dev/rsd3c bs=1m count=1
> dd if=/dev/zero of=/dev/rsd4c bs=1m count=1
> fdisk -iy sd3
> fdisk -iy sd4
> install
> [ ... usual install process ... ]
> /mnt/usr/sbin/installboot -v -r /mnt sd3

The installer will detect your install target is softraid crypto
and do that automatically. Why are you re-doing this again?

-ml

> newfs sd2i
> mount /dev/sd2i /mnt2
> dmesg > /mnt2/dmesg.txt
> fdisk sd0 > /mnt2/fdisk-sd0.txt
> fdisk sd1 > /mnt2/fdisk-sd1.txt
> fdisk sd2 > /mnt2/fdisk-sd2.txt
> fdisk sd3 > /mnt2/fdisk-sd3.txt
> fdisk sd4 > /mnt2/fdisk-sd4.txt
> 
> fdisk sd0 > /mnt2/fdisk-sd0.txt
> fdisk sd1 > /mnt2/fdisk-sd1.txt
> fdisk sd2 > /mnt2/fdisk-sd2.txt
> fdisk sd3 > /mnt2/fdisk-sd3.txt
> fdisk sd4 > /mnt2/fdisk-sd4.txt
> 
> bioctl sd3 > /mnt2/bioctl-sd3.txt
> 
> reboot

Re: NOT POSSIBLE: Fully encrypted system with keydisk

[Mike Larkin]

On Sat, Dec 12, 2015 at 12:51:33AM +0100, Stefan Wollny wrote:
> 
> 
> Gesendet??von??meinem??BlackBerry??10-Smartphone.
> ?? Originalnachricht ??
> ???On Sat, Dec 12, 2015 at 12:27:46AM +0100, Stefan Wollny wrote:
> > Am 12/11/15 um 18:34 schrieb Stefan Sperling:
> > >On Fri, Dec 11, 2015 at 05:44:36PM +0100, Stefan Wollny wrote:
> > >>fdisk(25692): syscall 54 "ioctl"
> > >>Abort trap
> > >>> disklabel sd3
> > >>disklabel(3120): syscall 54 "ioctl"
> > >>Abort trap
> > >This is obviously not quite right.
> > >It looks like you're using a snapshot with a pledge(2) bug.
> > >
> > >What snapshot are you booting? Please ensure that you're either
> > >booting 5.8 or the latest snapshot and send a complete dmesg
> > >if it is still failing.
> > A couple of test iterations later ...
> > 
> > [TLDR: Still no reboot into an unencrypted system]
> > 
> > 
> > These are the steps (annotated) I went through:
> > 
> > 
> > 
> > +++
> > s
> > 
> > Prior to running bsr.rd check the chain of boot devices,
> > has to be CD => sd0 => PXE
> > 's' to choose "shell"
> > fdisk sd0 => OK
> > fdisk sd1 => not OK
> > fdisk sd2 => not OK
> > cd /dev
> > sh ./MAKEDEV sd1
> > sh ./MAKEDEV sd2
> > cd /
> > fdisk -iy sd0
> > fdisk -iy sd1
> > fdisk -iy sd2
> > disklabel -E sd0
> > entire HD: FS type RAID, partition 'd'
> > disklabel -E sd1
> > entire HD: FS type RAID, partition 'e'
> > disklabel -E sd2
> > partition 'd', size 1M, FS type RAID
> > partition 'e', size 1M, FS type RAID
> > partition 'f', size 1M, FS type RAID
> > partition 'g', size 1M, FS type RAID
> > partition 'h', size 1M, FS type RAID
> > partition 'i', size , FS type 4.2BSD
> > bioctl -c C -l /dev/sd0d -k /dev/sd2d softraid0
> > bioctl -c C -l /dev/sd1e -k /dev/sd2e softraid0
> > cd /dev
> > sh ./MAKEDEV sd3
> > sh ./MAKEDEV sd4
> > cd /
> > dd if=/dev/zero of=/dev/rsd3c bs=1m count=1
> > dd if=/dev/zero of=/dev/rsd4c bs=1m count=1
> > fdisk -iy sd3
> > fdisk -iy sd4
> > install
> > [ ... usual install process ... ]
> > /mnt/usr/sbin/installboot -v -r /mnt sd3
> 
> The installer will detect your install target is softraid crypto
> and do that automatically. Why are you re-doing this again?
> 
> -ml
> 
> I was adviced to do so. With or without the system doesn't reboot but stopps 
> at the machine's splash screen for not finding a boot device. 
> 
> STEFAN ???

I'd try with a simpler config first, like just making a single softraid crypto
device, without a keydisk. See if that works first before moving on to more
complex configurations.

-ml

Re: NOT POSSIBLE: Fully encrypted system with keydisk

[Stefan Wollny]

Gesendet von meinem BlackBerry 10-Smartphone.
  Originalnachricht  
‎On Sat, Dec 12, 2015 at 12:27:46AM +0100, Stefan Wollny wrote:
> Am 12/11/15 um 18:34 schrieb Stefan Sperling:
> >On Fri, Dec 11, 2015 at 05:44:36PM +0100, Stefan Wollny wrote:
> >>fdisk(25692): syscall 54 "ioctl"
> >>Abort trap
> >>> disklabel sd3
> >>disklabel(3120): syscall 54 "ioctl"
> >>Abort trap
> >This is obviously not quite right.
> >It looks like you're using a snapshot with a pledge(2) bug.
> >
> >What snapshot are you booting? Please ensure that you're either
> >booting 5.8 or the latest snapshot and send a complete dmesg
> >if it is still failing.
> A couple of test iterations later ...
>
> [TLDR: Still no reboot into an unencrypted system]
>
>
> These are the steps (annotated) I went through:
>
>
>
> +++
> s
>
> Prior to running bsr.rd check the chain of boot devices,
> has to be CD => sd0 => PXE
> 's' to choose "shell"
> fdisk sd0 => OK
> fdisk sd1 => not OK
> fdisk sd2 => not OK
> cd /dev
> sh ./MAKEDEV sd1
> sh ./MAKEDEV sd2
> cd /
> fdisk -iy sd0
> fdisk -iy sd1
> fdisk -iy sd2
> disklabel -E sd0
> entire HD: FS type RAID, partition 'd'
> disklabel -E sd1
> entire HD: FS type RAID, partition 'e'
> disklabel -E sd2
> partition 'd', size 1M, FS type RAID
> partition 'e', size 1M, FS type RAID
> partition 'f', size 1M, FS type RAID
> partition 'g', size 1M, FS type RAID
> partition 'h', size 1M, FS type RAID
> partition 'i', size , FS type 4.2BSD
> bioctl -c C -l /dev/sd0d -k /dev/sd2d softraid0
> bioctl -c C -l /dev/sd1e -k /dev/sd2e softraid0
> cd /dev
> sh ./MAKEDEV sd3
> sh ./MAKEDEV sd4
> cd /
> dd if=/dev/zero of=/dev/rsd3c bs=1m count=1
> dd if=/dev/zero of=/dev/rsd4c bs=1m count=1
> fdisk -iy sd3
> fdisk -iy sd4
> install
> [ ... usual install process ... ]
> /mnt/usr/sbin/installboot -v -r /mnt sd3

The installer will detect your install target is softraid crypto
and do that automatically. Why are you re-doing this again?

-ml

I was adviced to do so. With or without the system doesn't reboot but stopps
at the machine's splash screen for not finding a boot device.

STEFAN ‎

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Anthony J. Bentley]

Kevin Chadwick writes:
> What is your problem with it, there are many VPN services promoted
> precisely for this issue as it completely rather than partially stops
> ISP's monitoring traffic like TalkTalks homesafe service that is
> likely hackable itself.

Why encrypt anything? Just run it through a VPN! Who needs SSH when you
can run telnet over a VPN? It completely protects the connection! Well,
except for the endpoint from the VPN to the destination server. And the
VPN provider itself can listen to or spoof whatever he wants. But hey,
who cares about that?

Re: ld.so behavior with $ORIGIN

[Theo de Raadt]

> > It would be that or
> > have the kernel store the whole path for the life of the process for
> > obtaining with sysctl()
> 
> That would be great. ps and top would be able to display the path too,
> pretty handy.

How did people get by without needing this in the last three decades?

Re: ld.so behavior with $ORIGIN

[Theo de Raadt]

> On Fri, Dec 11, 2015 at 10:18 AM, Theo de Raadt  
> wrote:
> >> Just found I can set LD_DEBUG to see the full translation process of ld.so.
> >> This seems to confirm what I've seen in the source: ld.so uses cwd
> >> instead of process file location for $ORIGIN interpolation.
> >  ^
> >
> > What is that?  Generally Unix has no way of doing this.  You can inspect
> > your executable's __progname, which is cloned from argv at crt startup,
> > but it may not contain an absolute path.  So what do you really mean here?
> 
> I'm not sure what Solaris does for this, but it looks like glibc on
> Linux does readlink("/proc/self/exe") and if that fails and the
> process trusts its environment** then it falls back to the
> LD_ORIGIN_PATH environment variable.  $ORIGIN then expands to
> dirname() of that.

Oh, I was certain that is what this would do.

That is why I said "Generally Unix has no way of doing this".

/proc/self/exe, or anything else like it, is DEFINATELY NOT
in POSIX or any other cross-vendor Unix standard.  

> I guess we could stick 'path' into an auxiliary vector value and have
> ld.so do the realpath() call if $ORIGIN is used?  It would be that or
> have the kernel store the whole path for the life of the process for
> obtaining with sysctl().  Right now it only stores the last component
> of the (resolved) original path in p_comm.

Quite expensive, for such a small need.

Since Unix operating systems don't have a way to do this in general,
how did this become part of the ld.so spec?

Re: NOT POSSIBLE: Fully encrypted system with keydisk

[Stefan Wollny]

Am 12/11/15 um 18:34 schrieb Stefan Sperling:

On Fri, Dec 11, 2015 at 05:44:36PM +0100, Stefan Wollny wrote:

fdisk(25692): syscall 54 "ioctl"
Abort trap

   disklabel sd3

disklabel(3120): syscall 54 "ioctl"
Abort trap

This is obviously not quite right.
It looks like you're using a snapshot with a pledge(2) bug.

What snapshot are you booting? Please ensure that you're either
booting 5.8 or the latest snapshot and send a complete dmesg
if it is still failing.

A couple of test iterations later ...

[TLDR: Still no reboot into an unencrypted system]


These are the steps (annotated) I went through:



+++
s

Prior to running bsr.rd check the chain of boot devices,
has to be CD => sd0 => PXE
's' to choose "shell"
fdisk sd0 => OK
fdisk sd1 => not OK
fdisk sd2 => not OK
cd /dev
sh ./MAKEDEV sd1
sh ./MAKEDEV sd2
cd /
fdisk -iy sd0
fdisk -iy sd1
fdisk -iy sd2
disklabel -E sd0
entire HD: FS type RAID, partition 'd'
disklabel -E sd1
entire HD: FS type RAID, partition 'e'
disklabel -E sd2
partition 'd', size 1M, FS type RAID
partition 'e', size 1M, FS type RAID
partition 'f', size 1M, FS type RAID
partition 'g', size 1M, FS type RAID
partition 'h', size 1M, FS type RAID
partition 'i', size , FS type 4.2BSD
bioctl -c C -l /dev/sd0d -k /dev/sd2d softraid0
bioctl -c C -l /dev/sd1e -k /dev/sd2e softraid0
cd /dev
sh ./MAKEDEV sd3
sh ./MAKEDEV sd4
cd /
dd if=/dev/zero of=/dev/rsd3c bs=1m count=1
dd if=/dev/zero of=/dev/rsd4c bs=1m count=1
fdisk -iy sd3
fdisk -iy sd4
install
[ ... usual install process ... ]
/mnt/usr/sbin/installboot -v -r /mnt sd3
newfs sd2i
mount /dev/sd2i /mnt2
dmesg > /mnt2/dmesg.txt
fdisk sd0 > /mnt2/fdisk-sd0.txt
fdisk sd1 > /mnt2/fdisk-sd1.txt
fdisk sd2 > /mnt2/fdisk-sd2.txt
fdisk sd3 > /mnt2/fdisk-sd3.txt
fdisk sd4 > /mnt2/fdisk-sd4.txt

fdisk sd0 > /mnt2/fdisk-sd0.txt
fdisk sd1 > /mnt2/fdisk-sd1.txt
fdisk sd2 > /mnt2/fdisk-sd2.txt
fdisk sd3 > /mnt2/fdisk-sd3.txt
fdisk sd4 > /mnt2/fdisk-sd4.txt

bioctl sd3 > /mnt2/bioctl-sd3.txt

reboot

+++


RESULT: No system start, the process stops immediately at the splash 
screen (=no boot device found?)


OK - here are the protocols as given above:

SD0
Disk: sd0geometry: 14593/255/63 [234441648 Sectors]
Offset: 0Signature: 0xAA55
  Starting Ending LBA Info:
 #: id  C   H   S -  C   H   S [ start:size ]
---
 0: 00  0   0   0 -  0   0   0 [ 0:   0 ] unused
 1: 00  0   0   0 -  0   0   0 [ 0:   0 ] unused
 2: 00  0   0   0 -  0   0   0 [ 0:   0 ] unused
*3: A6  0   1   2 -  14592 254  63 [  64: 234436481 ] 
OpenBSD


# /dev/rsd0c:
type: SCSI
disk: SCSI disk
label: Samsung SSD 850
duid: 9a2e9576361b4dd5
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 255
sectors/cylinder: 16065
cylinders: 14593
total sectors: 234441648
boundstart: 64
boundend: 234436545
drivedata: 0

16 partitions:
#size   offset  fstype [fsize bsize  cpg]
  c:2344416480 unused
  d:234436481   64 RAID

SD 1:
Disk: sd1geometry: 124519/255/63 [2000409264 Sectors]
Offset: 0Signature: 0xAA55
  Starting Ending LBA Info:
 #: id  C   H   S -  C   H   S [ start:size ]
---
 0: 00  0   0   0 -  0   0   0 [ 0:   0 ] unused
 1: 00  0   0   0 -  0   0   0 [ 0:   0 ] unused
 2: 00  0   0   0 -  0   0   0 [ 0:   0 ] unused
*3: A6  0   1   2 - 124518 254  63 [  64: 2000397671 ] 
OpenBSD


# /dev/rsd1c:
type: SCSI
disk: SCSI disk
label: Samsung SSD 850
duid: 5367a9a0fd3fe33c
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 255
sectors/cylinder: 16065
cylinders: 124519
total sectors: 2000409264
boundstart: 64
boundend: 2000397735
drivedata: 0

16 partitions:
#size   offset  fstype [fsize bsize  cpg]
  c:   20004092640 unused
  e:   2000397671   64 RAID

SD2
Disk: sd2geometry: 979/255/63 [15730688 Sectors]
Offset: 0Signature: 0xAA55
  Starting Ending LBA Info:
 #: id  C   H   S -  C   H   S [ start:size ]
---
 0: 00  0   0   0 -  0   0   0 [ 0:   0 ] unused
 1: 00  0   0   0 -  0   0   0 [ 0:   0 ] unused
 2: 00  0   0   0 -  0   0   0 [ 0:   0 ] unused

Current #1740 on a MacBook Pro 9,1.

[Christoph R. Murauer]

Hello !

If the message is not correct formated, I am sorry (SquirrelMail from my 
provider is not available at the moment).


I tried the latest snapshot #1740 from today on a MacBook Pro 9,1 (mid 
2012, the last one with optical drive and without Retina display).


Boot from USB worked, installed the first time with all default values 
from the installer - everything till X worked out-of-the-box. Second try 
with full disc encryption and GPT fails after the passphrase was entered 
with *can't read disk label, failed(96)* (full output message could be 
provided if someone needs it). Third install with MBR and full disc 
encryption worked without any problems till X (wrote this email on the 
machine).


asmc works including keyboard backlight (for the sensors see dmesg 
below). Suspend works, resume doesn't work. When I close the lid the 
machine suspends as it should. When I open the lid, the display stays 
black and the keyboard backlight is off. Pressing the power button for 
short time results in a shutdown - with no filesystem check at the next 
reboot.


Resolution in X after install :

$ xrandr -q
xrandr: Failed to get size of gamma for output default
Screen 0: minimum 1680 x 1050, current 1680 x 1050, maximum 1680 x 1050
default connected 1680x1050+0+0 0mm x 0mm
   1680x1050  0.00*

USB tethering using urndis worked without problems (dhclient needs - as 
always - two tries to get a connection using a Nexus 7).


If more informations are needed, let me know.

dmesg :

OpenBSD 5.8-current (GENERIC.MP) #1740: Fri Dec 11 11:38:58 MST 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
RTC BIOS diagnostic error 
df

real mem = 8509272064 (8115MB)
avail mem = 8247255040 (7865MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe1010 (83 entries)
bios0: vendor Apple Inc. version "MBP91.88Z.00D3.B08.1208081132" date 
08/08/2012

bios0: Apple Inc. MacBookPro9,1
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP HPET APIC SBST ECDT SSDT SSDT SSDT SSDT SSDT 
SSDT SSDT SSDT SSDT SSDT SSDT DMAR MCFG
acpi0: wakeup devices P0P2(S3) GFX0(S3) PEG1(S3) EC__(S4) GMUX(S3) 
HDEF(S3) RP01(S3) GIGE(S3) SDXC(S3) RP02(S3) ARPT(S3) RP03(S3) EHC1(S3) 
EHC2(S3) XHC1(S3) ADP1(S4) [...]

acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-3820QM CPU @ 2.70GHz, 1197.48 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT

cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i7-3820QM CPU @ 2.70GHz, 1197.29 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT

cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Core(TM) i7-3820QM CPU @ 2.70GHz, 1197.29 MHz
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT

cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Core(TM) i7-3820QM CPU @ 2.70GHz, 1197.29 MHz
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT

cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 0, core 3, package 0
cpu4 at mainbus0: apid 1 (application processor)
cpu4: Intel(R) Core(TM) i7-3820QM CPU @ 2.70GHz, 1197.29 MHz
cpu4: 

8-Port Serial Port Card

[Jordon]

I recently picked up a few PCI serial port cards from the junk pile at
work.  My intent is to put one in my soon-to-be-retired Soekris net5501
and install OpenBSD on it to turn it into an 8 port terminal switch.

I tried the cards in a different PC just to see if they would work. 
Unfortunately, none of them were supported.  Here is the info:

***

I had a pair of RocketPort uPCI Octa cards with a P/N of 5002265 They
each had the following dmesg:

unknown vendor 0x11fe product 0x0805 (class communications subclass
  miscellaneous, rev 0x01) at pci4 dev 9 function 0 not configured

***

I also had a Perle Systems card with a product number of 04003090

The dmesg from it was:

unknown vendor 0x155f product 0xb008 (class communications subclass
serial, rev 0x00)
 at pci4 dev 9 function 0 not configured
unknown vendor 0x155f product 0xb008 (class bridge subclass
miscellaneous, rev 0x00)
 at pci4 dev 9 function 1 not configured

***

I am more interested in getting the Perle card working because I already
have an 8-port cable for it (I only have a 4-port cable for the
RocketPort cards.)  It looks like FreeBSD supports the Perle card (though I
haven't tried it.
https://svnweb.freebsd.org/base/head/sys/dev/puc/pucdata.c?view=annotate#l820

My question is what would it take to get this driver ported to OpenBSD? 
Are they very different?  Or is it pretty straightforward?  Or is the
support already there but it needs the PCI IDs added to a list?  Or is
this ancient stuff with not enough demand to make it worthwhile?  If
someone is really interested in a Rocketport card, I could probably send
one to them.  As for the Perle card, I am downloading the current source
now and I intend to poke around a bit, but I really don't know what I am
doing.  My driver dev experience is limited to a very little bit of
linux coding I did at work. 


Jordon

IKEDv2 lost tunnel. How to reproduce at will, effects and work around.

[Daniel Ouellet]

I sure hope this will help.

***Setup***
Two server on 5.8. Establish VPN with IKEDv2. One side active, one side
passive. Use rsa keys, or pass phrase if you like.

Active side:
# cat /etc/iked.conf
ikev2 Ouellet active from re0 to 66.63.5.250 from 66.63.50.16/28 to
0.0.0.0/0 peer 66.63.5.250

Passive side:
# cat /etc/iked.conf
ikev2 Ouellet passive from em0 to 108.56.142.37 from 0.0.0.0/0 to
66.63.50.16/28 peer 108.56.142.37

***Issues***
1. On heavy traffic, you will get many instance of SAD that will only
get clean up on the expiration of the lifetime in time, even if the
lifetiem is size has pass multiple times. Meaning clean up is only done
on timer, not on data limit reach.

2. On heavy download the destination (Passive side), when the data
limits is reach in a few occasion, the passive side wil try to change
the tunnel to use NAT-T, even if there is no NAT and then the only
solution is to stop/start the active side to establish the tunnel again.

***How to trigger and reproduce at will***
To easily trigger the issue often, just reduce the default with adding
on both sides a much shorter life time

lifetime 1m bytes 100k

as this:

ikev2 Ouellet active from re0 to 66.63.5.250 from 66.63.50.16/28 to
0.0.0.0/0 peer 66.63.5.250 lifetime 1m bytes 100k

And then just watch the logs live with
tail -f /var/log/daemon | grep iked
on passive side, you will see very quickly this:


Dec 11 20:01:32 tunnel iked[1801]: pfkey_reply: message: No such process
Dec 11 20:01:32 tunnel iked[1801]: ikev2_pld_delete: deleted 1 spis
Dec 11 20:01:32 tunnel iked[1801]: ikev2_msg_send: INFORMATIONAL
response from 66.63.5.250:500 to 108.56.142.37:500 msgid 3, 80 bytes, NAT-T


Then you will loose access to the tunnel completely and it will not
recover until you manually reset the active side with rc.d/iked stop and
start.

The data limit is small, so you can trigger it with just:

ping -s 1500 66.63.5.250 from the active side of the network. Or what
ever way you want to generate traffic and before you know it you coudl
see this:

# ipsecctl -sa | wc -l
 493

and the number of SAD will ONLY get reduce when the time limits is
reach, even if they are not valid anymore and have been trigger by the
data limits.

May be the clean up should happen on both, time and data limits. Just a
thought.

***Work Around***
Now to work around the problem for now, simply change the lifetime of
the PASSIVE side. I just pick 2x the Active side for both time and data
so that it NEVER trigger the NAT-T issue. Not an ideal solution, but for
now it fix the lost of VPN at random time.

You can test and do the same as above to see it with only have the
active side with the same

lifetime 1m bytes 100k

and then the passive side with

lifetime 2m bytes 200k

And just flow traffic.

You still will see the huge increase in SAD on the active side as the
data limits get reach and new child get created, as they don't get clean
up then, but only on time limits reach.

But this way at a minimum, you will NOT loose your VPN.

The same issue show up as well even if both side are active. It's more
like a timing issue I guess possibly, but really if a VPN works without
NAT I think it should never try to establish NAT-T anyway, specially if
it has pass traffic constantly all the way to 500Mb, being he default
and when the VPN carry huge traffic, may be it should clean up the old
child on the SAD when a data limit is reach and a new child is created
instead of doing it only on time limit reach, so that if you decide to
setup no limit on time, then you box don't explode because of lack of
resources or what not and old child are not release.

Hopefully this will be useful to someone as it took me a week to isolate
why in hell I loose VPN at random time on an otherwise perfectly working
VPN.

Best,

Daniel

Cleaning up function prototypes... or not

[Christian Weisgerber]

When you remove code, it's easy to forget function declarations.
That made me wonder how many orphan prototypes there are that refer
to functions that no longer exist.

There is an intriguing gcc option.  I'll quote its description in
full, from the info manual:

`-aux-info FILENAME'
 Output to the given filename prototyped declarations for all
 functions declared and/or defined in a translation unit, including
 those in header files.  This option is silently ignored in any
 language other than C.

 Besides declarations, the file indicates, in comments, the origin
 of each declaration (source file and line), whether the
 declaration was implicit, prototyped or unprototyped (`I', `N' for
 new or `O' for old, respectively, in the first character after the
 line number and the colon), and whether it came from a declaration
 or a definition (`C' or `F', respectively, in the following
 character).  In the case of function definitions, a K list
 of arguments followed by their declarations is also provided,
 inside comments, after the declaration.

I built a kernel with -aux-info. (After make config, edit Makefile
and add something like -aux-info ${@:.o=.X} to NORMAL_C.)

That produces a lot of raw data that can be further processed with
the usual Unix text tools.

To find orphan prototypes, I tried two approaches:
(1) Check the -aux-info output for functions that are declared but
not defined.
(2) Compare the functions that are declared in the -aux-info output
with the kernel symbol table (nm -g bsd).

I then picked a handful of suspect function names turned up by
either scheme and grepped the tree.  Unfortunately, both approaches
are subject to false positives.  (1) spits out functions that are
actually implemented in assembly.  (2) runs into functions that are
defined, but don't show up in the symbol table because they are
inlined.  Both approaches turn up function definitions that are
behind various #ifdef guards. There are probably more problems, but
I quickly lost interest when it became obvious that the results
were dominated by false positives.

No, this is not a success story.

Something else fell out of the -aux-info run.  We still have tons
of function definitions that aren't ANSI-fied.  I wonder whether
it would be worth to clean that up in one final push.

And another pattern showed up:

int func();

int func()
{
...
}

Neither of these is ANSI style.  If a function doesn't take parameters,
the parameter list needs to say "void".  Looks like somebody forgot
about this--e.g. when ansifying the network code.  I thought about
cleaning these up, but then there's little point when we still have
so much unansified code anyway.

Also, as useful as -aux-info is, it requires actual compiling, so
it won't help with MD code for other architectures or drivers that
aren't configured in the kernel.

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

Re: NOT POSSIBLE: Fully encrypted system with keydisk

[Stefan Sperling]

On Sat, Dec 12, 2015 at 12:27:46AM +0100, Stefan Wollny wrote:
> Am 12/11/15 um 18:34 schrieb Stefan Sperling:
> >On Fri, Dec 11, 2015 at 05:44:36PM +0100, Stefan Wollny wrote:
> >>fdisk(25692): syscall 54 "ioctl"
> >>Abort trap
> >>>   disklabel sd3
> >>disklabel(3120): syscall 54 "ioctl"
> >>Abort trap
> >This is obviously not quite right.
> >It looks like you're using a snapshot with a pledge(2) bug.
> >
> >What snapshot are you booting? Please ensure that you're either
> >booting 5.8 or the latest snapshot and send a complete dmesg
> >if it is still failing.
> A couple of test iterations later ...
> 
> [TLDR: Still no reboot into an unencrypted system]
> 
> These are the steps (annotated) I went through:

I cannot see anything obviously wrong in there.

Perhaps the BIOS has some issue with this setup.
Could you try the same procedure on a different machine
to check if it works there?

Another thing you could try is clearing the bootable flag
in the MBR of your key disk with fdisk (run fdisk -e sd2;
type the commands 'flag 3 0' and 'exit'). Perhaps the BIOS
is looking for something to boot on the keydisk and crashes?

Re: Can't install dovecot-2.2.19p0 because of libraries

[Stuart Henderson]

Wait and try again, or build it yourself from ports. If you want to avoid this
happening, watch out for commits to shlib_version files and hold off on updating
for a couple of days.


On 2015-12-11, Jiri Navratil  wrote:
> Hello,
>
> I just upgraded amd64 via bsd.rd snapshot to 5.8 GENERIC.MP#1737 amd64
>
> after sysmerge
> during pkg_add -ui -F update -F updatedepends
>
> I got quirks-2.167 signed on 2015-12-10T00:43:20Z
> Can't install dovecot-2.2.19p0 because of libraries
>|library crypto.36.1 not found
>| /usr/lib/libcrypto.so.32.0 (system): bad major
>| /usr/lib/libcrypto.so.34.0 (system): bad major
>| /usr/lib/libcrypto.so.35.0 (system): bad major
>| /usr/lib/libcrypto.so.36.0 (system): minor is too small
>| /usr/lib/libcrypto.so.37.0 (system): bad major
>|library ssl.37.1 not found
>| /usr/lib/libssl.so.32.0 (system): bad major
>| /usr/lib/libssl.so.33.0 (system): bad major
>| /usr/lib/libssl.so.36.0 (system): bad major
>| /usr/lib/libssl.so.37.0 (system): minor is too small
>| /usr/lib/libssl.so.38.0 (system): bad major
> Direct dependencies for dovecot-2.2.19->2.2.19p0 resolve to xz-5.2.2
> bzip2-1.0.6p7 libiconv-1.14p3 lz4-0.131p0
> Full dependency tree is libiconv-1.14p3 lz4-0.131p0 xz-5.2.2
> bzip2-1.0.6p7
> Couldn't find updates for dovecot-2.2.19
>
> I switched from ftp5.eu.openbsd.org to
>
> PKG_PATH=ftp://ftp.openbsd.org/pub/OpenBSD/snapshots/packages/amd64
>
> but without change.
>
> What I should do regarding crypto and ssl reported errors?
>
> Can I do something to have dovecot upgraded or shall I just wait few
> hours / days and repeat the upgrade via bsd.rd?
>
> Thank you,
> Jiri 

Wifi Configuration | Realtek RTL8191SE

[Luiz Moraes]

Hi Everyone,
Im a Linux user (Slackware) and now i decided to try OpenBSD as my main
OS on my laptop, the only thing that i couldn't solve is to make my Wifi
card works on OpenBSD.
 It's a Realtek RTL8191SE PCI. I tried to compile Linux Driver with no
success and there is no ndiswrapper substitute on OpenBSD. How can i solve?
Is there anyone here that already had this kind of challenge?

Some commands output:

*#dmesg | grep pci1 *

*pci1 at ppb0 bus 2*
*vendor "Realtek". unknown product 0x8171 (class network subclass
miscellaneous, rev 0x10) at pci1 dev 0 funcion 0 not configured*

*#pcidump*

*Domain /dev/pci0:*
...
*2:0:0:  Realtek uknown*
*3:0:0: Realtek 8101E  *(Essa é a re0, ethernet wired do note)



Luiz Diego Fernandes de Moraes

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Stuart Henderson]

On 2015-12-11, Constantine A. Murenin  wrote:
> On 11 December 2015 at 02:58, Thijs van Dijk  wrote:
>> On 11 December 2015 at 05:51, Andy Bradford 
>> wrote:
>>
>>> If one wants privacy on a website then more is required than just HTTPS.
>>>
>>
>> Right. *I* just want a reasonable (256-bit) guarantee that the signify keys
>> on my screen are the ones the OpenBSD authors intended me to see.
>>
>> I currently just assume they are correct because it'd be enormously complex
>> to spoof the entire OpenBSD distribution, but I souldn't have to rely on
>> "security through effort involved".
>>
>> Remember the guy who tried to securely download PuTTY? He couldn't
>> 
>
> And I couldn't access his web-site from an OpenBSD box:
>
> % lynx -dump 
> https://noncombatant.org/2014/03/03/downloading-software-safely-is-nearly-impossible/
>
> Looking up noncombatant.org
> Making HTTPS connection to noncombatant.org
> SSL callback:unable to get local issuer certificate, preverify_ok=0, 
> ssl_okay=0
> Retrying connection without TLS.
> Looking up noncombatant.org
> Making HTTPS connection to noncombatant.org
> Alert!: Unable to make secure connection to remote host.
>
> lynx: Can't access startfile
> https://noncombatant.org/2014/03/03/downloading-software-safely-is-nearly-impossible/
> %
>
> C.
>
>

Works in -current - update /etc/ssl/cert.pem.

Re: NOT POSSIBLE: Fully encrypted system with keydisk

[Alexander Hall]

On December 11, 2015 1:27:52 AM GMT+01:00, Stuart Henderson 
 wrote:
>On 2015-12-10, Stefan Wollny  wrote:

>> YES: I did 'bioctl -C force -c C -l /dev/sd0d -k /dev/sd1d softraid0'
>> YES: I did again 'sh ./MAKEDEV all' to catch the newly created sd2
>
>In the above step, you have run yourself out of space on the
>ramdisk by creating a load of device nodes that you don't have
>space for and don't need.

Indeed. In particular, you tend to run out of inodes.

/Alexander 

When iked re-key, leave ghost behind

[Daniel Ouellet]

One question. Is it the only way to re-key the iked process when it
reach it's 3 hours usage and/or the 500 Mb data exchange to restart a
new process?

Isn't it possible to kill the old one then that is not use anymore and
stop having some routing problem that may be cause by it.

I collect a HUGE amount of old process that appear to finally get clean
after a while, but I wonder if it actually need to have a process
restart instead of just the key change on that same process, or if it
needs to be a new process, then make sure they old one is killed?

Here is an example of how many times there is old process here. See logs
below for examples.

Also, one question, researching on google I saw a few example done as
below and it create less duplicate process for the same flow and wonder
if that's not better and it appear to be more stable a bit. In both
cases, I still sadly need to reset the iked originating side regularly
however, just wonder if the simpler solution is not better and if not why?

One line setup and need less restart of the iked daemon.

ikev2 Ouellet active from re0 to 66.63.5.250 from 66.63.50.16/28 to
0.0.0.0/0 peer 66.63.5.250

And setup as per the man page:

ikev2 Ouellet active from re0 to 66.63.5.250
ikev2 Ouellet active from 66.63.50.16/28 to 0.0.0.0/0 peer 66.63.5.250

And here is the logs for how many times there is ghost process left
behind that are cleared up hours after new process have been created.

If a process has to be re-created, then why not kill the old one before
doing so? Just wonder if that may not help the stability and possibly
eliminate the constant needs for the daemon restart.

Thanks

Daniel

Example of logs with left over ghost iked process.

# cat daemon | grep "pfkey_sa_last_used: message: No such process"
Dec 11 09:41:06 gateway iked[28392]: pfkey_sa_last_used: message: No
such process
Dec 11 09:41:06 gateway iked[28392]: pfkey_sa_last_used: message: No
such process
Dec 11 09:42:06 gateway iked[28392]: pfkey_sa_last_used: message: No
such process
Dec 11 09:42:06 gateway iked[28392]: pfkey_sa_last_used: message: No
such process
Dec 11 09:43:06 gateway iked[28392]: pfkey_sa_last_used: message: No
such process
Dec 11 09:44:06 gateway iked[28392]: pfkey_sa_last_used: message: No
such process
Dec 11 09:45:06 gateway iked[28392]: pfkey_sa_last_used: message: No
such process
Dec 11 09:58:06 gateway iked[28392]: pfkey_sa_last_used: message: No
such process
Dec 11 10:26:06 gateway iked[28392]: pfkey_sa_last_used: message: No
such process
Dec 11 10:45:07 gateway iked[28392]: pfkey_sa_last_used: message: No
such process
Dec 11 10:52:07 gateway iked[28392]: pfkey_sa_last_used: message: No
such process
Dec 11 11:13:07 gateway iked[28392]: pfkey_sa_last_used: message: No
such process
Dec 11 11:13:07 gateway iked[28392]: pfkey_sa_last_used: message: No
such process
Dec 11 11:14:07 gateway iked[28392]: pfkey_sa_last_used: message: No
such process
Dec 11 11:14:07 gateway iked[28392]: pfkey_sa_last_used: message: No
such process
Dec 11 11:15:07 gateway iked[28392]: pfkey_sa_last_used: message: No
such process
Dec 11 11:15:07 gateway iked[28392]: pfkey_sa_last_used: message: No
such process
Dec 11 11:16:07 gateway iked[28392]: pfkey_sa_last_used: message: No
such process
Dec 11 11:44:08 gateway iked[28392]: pfkey_sa_last_used: message: No
such process
Dec 11 11:44:08 gateway iked[28392]: pfkey_sa_last_used: message: No
such process
Dec 11 11:45:08 gateway iked[28392]: pfkey_sa_last_used: message: No
such process
Dec 11 11:55:08 gateway iked[28392]: pfkey_sa_last_used: message: No
such process
# zcat daemon.?.gz | grep "pfkey_sa_last_used: message: No such process"
| sort -r
Dec 10 22:32:57 gateway iked[22948]: pfkey_sa_last_used: message: No
such process
Dec 10 22:32:57 gateway iked[22948]: pfkey_sa_last_used: message: No
such process
Dec 10 22:31:57 gateway iked[22948]: pfkey_sa_last_used: message: No
such process
Dec 10 22:31:57 gateway iked[22948]: pfkey_sa_last_used: message: No
such process
Dec 10 22:25:57 gateway iked[22948]: pfkey_sa_last_used: message: No
such process
Dec 10 22:11:57 gateway iked[22948]: pfkey_sa_last_used: message: No
such process
Dec 10 22:07:57 gateway iked[22948]: pfkey_sa_last_used: message: No
such process
Dec 10 21:45:57 gateway iked[22948]: pfkey_sa_last_used: message: No
such process
Dec 10 00:00:32 gateway iked[18024]: pfkey_sa_last_used: message: No
such process
Dec 10 00:00:32 gateway iked[18024]: pfkey_sa_last_used: message: No
such process
Dec  9 23:59:32 gateway iked[18024]: pfkey_sa_last_used: message: No
such process
Dec  9 23:59:32 gateway iked[18024]: pfkey_sa_last_used: message: No
such process
Dec  9 23:58:32 gateway iked[18024]: pfkey_sa_last_used: message: No
such process
Dec  9 23:58:32 gateway iked[18024]: pfkey_sa_last_used: message: No
such process
Dec  9 23:57:32 gateway iked[18024]: pfkey_sa_last_used: message: No
such process
Dec  9 23:57:32 gateway iked[18024]: pfkey_sa_last_used: message: No
such process
Dec  9 23:56:32 

Re: Wifi Configuration | Realtek RTL8191SE

[Stefan Sperling]

On Fri, Dec 11, 2015 at 02:37:54PM -0200, Luiz Moraes wrote:
> Hi Stefan,
> I already downloaded from http://firmware.openbsd.org/firmware/5.8/ the
> firmwares *rtwn*, *rsu and* u*rtwn *and installed them all with *fw_update*,
> later i restarted the laptop but the status on *dmesg *is the same.

There's a difference between driver and firmware code.
The driver runs on the OpenBSD kernel (it's part of the /bsd file)
and the firmare is loaded into the device as part of making
the device operational.

The rtwn(4) driver only supports RTL 8188CE devices at present.
Your chip is a cousin of that chip, but it's different and the
driver does not know how to make it work yet. Once the driver
supports your chip, the required firmware will also be shipped
in the rtwn-firmware package.

> I really would like to can keep OpenBSD as the main OS, but maybe i'll
> have to get FreeBSD to use the *ndisgen (*Is the ndiswrapper for FreeBSD
> and DragonflyBSD).

You could also use a support USB wireless device, for now.
Run this command:
  man -k wireless
to see a list of drivers and look at the USB ones.

With some effort you'll be able to find a supported device, for sure.
I often find supported devices on ebay for just 1 euro + shipping.

You can also find some USB devices supported by run(4), urtwn(4),
or athn(4) sold new in some stores around the world. But with
used devices chances of support are somewhat higher.

If your machine is a laptop that has a cardbus or express card slot,
you could also try to find a cardbus card supported by drivers such
as ath(4) and ral(4) (+ cardbus -> express card adapter if needed).
These tend to work very well.

Note that the time you would spend on hunting down a supported device
is very small compared to the time it takes to add code to the driver
to support your device. Eventually somebody (maybe me) may find time
to add this support. It would take me at least a week of sitting down
and working hard. I'd need to take that time out of other things in
life, so I cannot promise anything. Developers who have never done
this before would need even more time.
That said, my plan already was, before your mail, to support more realtek
devices in rtwn(4) eventually. I just don't know when it will happen.

> Can i get the *ndisgen *from FreeBSD and run on OpenBSD? (I woulnd like
> to change it, but if the OpenBSD doesnt give me options i'll have to find a
> way to keep me with it)

No. There is no support for binary blobs in OpenBSD, and there never will be.
We prefer writing code that makes blobs unnecessary.

Re: Wifi Configuration | Realtek RTL8191SE

[Luiz Moraes]

Stefan,
   Thank you very very much for your attention. When i grow up, i would
like to be like you =P. Unfortunatelly I don't program anymore, to get the
knowledge to do this i'll spend a lot of time, but it's my intention to
come back to study computer programming and maybe in a future helps the
OpenBSD team.
I understand your cares to keep the originality of the OS and that's
what makes me and others to prefer to use the OpenBSD.

Thank you very much!



Luiz Diego Fernandes de Moraes


2015-12-11 15:28 GMT-02:00 Stefan Sperling :

> On Fri, Dec 11, 2015 at 02:37:54PM -0200, Luiz Moraes wrote:
> > Hi Stefan,
> > I already downloaded from http://firmware.openbsd.org/firmware/5.8/
> the
> > firmwares *rtwn*, *rsu and* u*rtwn *and installed them all with
> *fw_update*,
> > later i restarted the laptop but the status on *dmesg *is the same.
>
> There's a difference between driver and firmware code.
> The driver runs on the OpenBSD kernel (it's part of the /bsd file)
> and the firmare is loaded into the device as part of making
> the device operational.
>
> The rtwn(4) driver only supports RTL 8188CE devices at present.
> Your chip is a cousin of that chip, but it's different and the
> driver does not know how to make it work yet. Once the driver
> supports your chip, the required firmware will also be shipped
> in the rtwn-firmware package.
>
> > I really would like to can keep OpenBSD as the main OS, but maybe
> i'll
> > have to get FreeBSD to use the *ndisgen (*Is the ndiswrapper for FreeBSD
> > and DragonflyBSD).
>
> You could also use a support USB wireless device, for now.
> Run this command:
>   man -k wireless
> to see a list of drivers and look at the USB ones.
>
> With some effort you'll be able to find a supported device, for sure.
> I often find supported devices on ebay for just 1 euro + shipping.
>
> You can also find some USB devices supported by run(4), urtwn(4),
> or athn(4) sold new in some stores around the world. But with
> used devices chances of support are somewhat higher.
>
> If your machine is a laptop that has a cardbus or express card slot,
> you could also try to find a cardbus card supported by drivers such
> as ath(4) and ral(4) (+ cardbus -> express card adapter if needed).
> These tend to work very well.
>
> Note that the time you would spend on hunting down a supported device
> is very small compared to the time it takes to add code to the driver
> to support your device. Eventually somebody (maybe me) may find time
> to add this support. It would take me at least a week of sitting down
> and working hard. I'd need to take that time out of other things in
> life, so I cannot promise anything. Developers who have never done
> this before would need even more time.
> That said, my plan already was, before your mail, to support more realtek
> devices in rtwn(4) eventually. I just don't know when it will happen.
>
> > Can i get the *ndisgen *from FreeBSD and run on OpenBSD? (I woulnd
> like
> > to change it, but if the OpenBSD doesnt give me options i'll have to
> find a
> > way to keep me with it)
>
> No. There is no support for binary blobs in OpenBSD, and there never will
> be.
> We prefer writing code that makes blobs unnecessary.

Re: NOT POSSIBLE: Fully encrypted system with keydisk

[Stefan Sperling]

On Fri, Dec 11, 2015 at 05:44:36PM +0100, Stefan Wollny wrote:
> fdisk(25692): syscall 54 "ioctl"
> Abort trap
> >   disklabel sd3
> disklabel(3120): syscall 54 "ioctl"
> Abort trap

This is obviously not quite right.
It looks like you're using a snapshot with a pledge(2) bug.

What snapshot are you booting? Please ensure that you're either
booting 5.8 or the latest snapshot and send a complete dmesg
if it is still failing.

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Oriol Demaria]

I agree, but no one mentioned DANE, I think that's the future and the
way to go. With DANE in theory you wouldn't need a CA. I think it's an
excellent way to establish authenticity of your content. Problem is that
no browser supports it by default, and DNSsec use is marginal.

Regards,

Giancarlo Razzolini writes:

> Em 10-12-2015 20:03, Christian Weisgerber escreveu:
>> The true elephant in the room is that I can't get the current OpenBSD
>> source tree securely.  (Well, _I_ can if push comes to shove, but
>> the general user community can't.)  CVSync?  No integrity or
>> authenticity.  AnonCVS over SSH?  Nope, no integrity or authenticity
>> because the mirror itself got the tree over CVSync.  Assuming you
>> trust the mirror in the first place.
>
> I agree with you. We don't want TLS to hide the fact that we are
> accessing the openbsd site. We want TLS to get a little extra confidence
> that what we are seeing on our screen is what the OpenBSD devs wanted us
> to see. Someone mentioned signify keys also. Nowadays if I want to be
> (kind of) sure I got everything right, I need to download the files from
> different mirrors, using different internet connections, using vpn's and
> tor, etc.
>
> The TLS could be implemented on a non mandatory way, you don't need to
> redirect HTTP connections to HTTPS ones. But it would be nice to have
> the option, at least.
>
> Cheers,
> Giancarlo Razzolini

-- 
Oriol Demaria
0x58415679

Can't install dovecot-2.2.19p0 because of libraries

[Jiri Navratil]

Hello,

I just upgraded amd64 via bsd.rd snapshot to 5.8 GENERIC.MP#1737 amd64

after sysmerge
during pkg_add -ui -F update -F updatedepends

I got quirks-2.167 signed on 2015-12-10T00:43:20Z
Can't install dovecot-2.2.19p0 because of libraries
|library crypto.36.1 not found
| /usr/lib/libcrypto.so.32.0 (system): bad major
| /usr/lib/libcrypto.so.34.0 (system): bad major
| /usr/lib/libcrypto.so.35.0 (system): bad major
| /usr/lib/libcrypto.so.36.0 (system): minor is too small
| /usr/lib/libcrypto.so.37.0 (system): bad major
|library ssl.37.1 not found
| /usr/lib/libssl.so.32.0 (system): bad major
| /usr/lib/libssl.so.33.0 (system): bad major
| /usr/lib/libssl.so.36.0 (system): bad major
| /usr/lib/libssl.so.37.0 (system): minor is too small
| /usr/lib/libssl.so.38.0 (system): bad major
Direct dependencies for dovecot-2.2.19->2.2.19p0 resolve to xz-5.2.2
bzip2-1.0.6p7 libiconv-1.14p3 lz4-0.131p0
Full dependency tree is libiconv-1.14p3 lz4-0.131p0 xz-5.2.2
bzip2-1.0.6p7
Couldn't find updates for dovecot-2.2.19

I switched from ftp5.eu.openbsd.org to

PKG_PATH=ftp://ftp.openbsd.org/pub/OpenBSD/snapshots/packages/amd64

but without change.

What I should do regarding crypto and ssl reported errors?

Can I do something to have dovecot upgraded or shall I just wait few
hours / days and repeat the upgrade via bsd.rd?

Thank you,
Jiri 

-- 
Jiri Navratil, http://kouc.navratil.cz, +420 222 767 131

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Kamil Cholewiński]

> The official CDs have the signify key physically printed on them.

You press a new CD, print a new cover, etc.

> If you want to rely on third parties, I can send you a copy of the
> signify keys, signed by my PGP key.  How would that help you at all?

Sounds reasonable to me.

Mg and extensions.

[Peter Fraser]

I have been an Emac user for 20 plus years, and I often look at mg to replace
it.
The functionality of mg is getting close.

To get some degree of programmability, I suggest that you could implement
Emac's "name-last-kbd-macro"
then allow one to bind that named-kbd-macro to a key.

To be really useful it be necessary to allow the definition of keyboard macros
to be in the startup file
and also to  implement Emac's register commands.

Re: ld.so behavior with $ORIGIN

[Theo de Raadt]

> Just found I can set LD_DEBUG to see the full translation process of ld.so.
> This seems to confirm what I've seen in the source: ld.so uses cwd
> instead of process file location for $ORIGIN interpolation.
 ^

What is that?  Generally Unix has no way of doing this.  You can inspect
your executable's __progname, which is cloned from argv at crt startup,
but it may not contain an absolute path.  So what do you really mean here?

Re: Wifi Configuration | Realtek RTL8191SE

[Christoph R. Murauer]

Hello !

As workaround you could look - for example - at the following USB WiFi
adapter.

TP-LINK WN725NN (should be that model but I am not 100% sure)
Edimax EW-7811Un

Booth work (not perfect) with urtwn. I had to many WiFi networks
around me so, I switched back to a Android tablet and use USB
tethering for my internet connection (LTE).


> Stefan,
>Thank you very very much for your attention. When i grow up, i
> would
> like to be like you =P. Unfortunatelly I don't program anymore, to get
> the
> knowledge to do this i'll spend a lot of time, but it's my intention
> to
> come back to study computer programming and maybe in a future helps
> the
> OpenBSD team.
> I understand your cares to keep the originality of the OS and
> that's
> what makes me and others to prefer to use the OpenBSD.
>
> Thank you very much!
>
>
>
> Luiz Diego Fernandes de Moraes
>
>
> 2015-12-11 15:28 GMT-02:00 Stefan Sperling :
>
>> On Fri, Dec 11, 2015 at 02:37:54PM -0200, Luiz Moraes wrote:
>> > Hi Stefan,
>> > I already downloaded from
>> http://firmware.openbsd.org/firmware/5.8/
>> the
>> > firmwares *rtwn*, *rsu and* u*rtwn *and installed them all with
>> *fw_update*,
>> > later i restarted the laptop but the status on *dmesg *is the
>> same.
>>
>> There's a difference between driver and firmware code.
>> The driver runs on the OpenBSD kernel (it's part of the /bsd file)
>> and the firmare is loaded into the device as part of making
>> the device operational.
>>
>> The rtwn(4) driver only supports RTL 8188CE devices at present.
>> Your chip is a cousin of that chip, but it's different and the
>> driver does not know how to make it work yet. Once the driver
>> supports your chip, the required firmware will also be shipped
>> in the rtwn-firmware package.
>>
>> > I really would like to can keep OpenBSD as the main OS, but
>> maybe
>> i'll
>> > have to get FreeBSD to use the *ndisgen (*Is the ndiswrapper for
>> FreeBSD
>> > and DragonflyBSD).
>>
>> You could also use a support USB wireless device, for now.
>> Run this command:
>>   man -k wireless
>> to see a list of drivers and look at the USB ones.
>>
>> With some effort you'll be able to find a supported device, for
>> sure.
>> I often find supported devices on ebay for just 1 euro + shipping.
>>
>> You can also find some USB devices supported by run(4), urtwn(4),
>> or athn(4) sold new in some stores around the world. But with
>> used devices chances of support are somewhat higher.
>>
>> If your machine is a laptop that has a cardbus or express card slot,
>> you could also try to find a cardbus card supported by drivers such
>> as ath(4) and ral(4) (+ cardbus -> express card adapter if needed).
>> These tend to work very well.
>>
>> Note that the time you would spend on hunting down a supported
>> device
>> is very small compared to the time it takes to add code to the
>> driver
>> to support your device. Eventually somebody (maybe me) may find time
>> to add this support. It would take me at least a week of sitting
>> down
>> and working hard. I'd need to take that time out of other things in
>> life, so I cannot promise anything. Developers who have never done
>> this before would need even more time.
>> That said, my plan already was, before your mail, to support more
>> realtek
>> devices in rtwn(4) eventually. I just don't know when it will
>> happen.
>>
>> > Can i get the *ndisgen *from FreeBSD and run on OpenBSD? (I
>> woulnd
>> like
>> > to change it, but if the OpenBSD doesnt give me options i'll have
>> to
>> find a
>> > way to keep me with it)
>>
>> No. There is no support for binary blobs in OpenBSD, and there never
>> will
>> be.
>> We prefer writing code that makes blobs unnecessary.

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Kevin Chadwick]

> Kevin Chadwick writes:
> > The cvs page fingerprint page could be https enabled, however you can
> > use googles cache over https, also buy a CD to help the project greatly
> > would do far more for world security than TLS everywhere and even look
> > at mailing list archives over https as a web of trust.
> > 
> > ISPs snooping is a compelling reason but not enough for me to adopt
> > HSTS, a VPN makes more sense. I changed my ISP instead though ;).  
> 
> There are valid complaints about HTTPS (generally involving the CA
> system, sthen brought some of them up), but some of these responses are
> just ridiculous. I mean, really? "ISPs snooping is a compelling reason
> but not enough for me to adopt SSH instead of telnet, a VPN makes more
> sense."
> 

If you are going to quote and criticise a comment then you should

a.) Get the quote right
b.) backup your criticisms

What is your problem with it, there are many VPN services promoted
precisely for this issue as it completely rather than partially stops
ISP's monitoring traffic like TalkTalks homesafe service that is
likely hackable itself.

HSTS is not telnet?? it is something that I looked into in the early
days of it's support and decided that unfortunately I could not
deploy it on my site as I believe it still means all of a domain must
use https once a browser has been notified for x time period as tracking
individual pages would be a huge burden for browsers.

> And you would trust signify keys from Google Cache? Come on.

Do I trust google... with this yes, as much as OpenBSD especially
considering they were acquired over http, of course not and I never
said I did. My meaning (if you had actually read my previous thread
mails) was that a couple of pages over https would be an improvement
but all of OpenBSD.org would be sub optimum. I'm not trying to avoid
the NSA. The point is that it's not the biggest issue in the world as
you can confirm in various ways like getting them over https as a
*second* check and it is hardly likely that a hacker can modify both
(same network as openbsd.org) and not get noticed. I'm guessing the NSA
avoid getting any snooping noticed btw, unless it's on purpose!

-- 

KISSIS - Keep It Simple So It's Securable