Re: Bootloader on USB stick fails with "root device not found"

2021-02-10 Thread Frank Beuth

On Tue, Feb 02, 2021 at 10:50:39PM +0100, Stefan Sperling wrote:

The idea of protecting key disks with a passphrase (two-factor auth) has
been raised before. It has not been implemented yet, simply because nobody
has done the work. A search of the mailing list archives should yield
some prior discussion.


How about backup keys, so I can have a backup passphrase stored 
somewhere safely that works even if I lose my keydisk?


FWIW I ran into the same problem as the OP when trying to put the 
bootloader on external media.




Re: Microsoft's war on plain text email in open source

2020-08-27 Thread Frank Beuth

On Wed, Aug 26, 2020 at 05:44:12PM -0700, Constantine A. Murenin wrote:
Why OpenBSD is to blame when Gmail -- after so many years -- still 
doesn't have proper support for sending text-based attachments the 
right way?


Because large corporations are always right, and the idea is to bend the 
world to suit the needs of the Microsofts and Googles.




Microsoft's war on plain text email in open source

2020-08-26 Thread Frank Beuth
"Linux kernel development  which is driven by plain-text email 
discussion  needs better or alternative collaborative tooling "to bring 
in new contributors and maintain and sustain Linux in the future," says 
Sarah Novotny, Microsoft's representative on the Linux Foundation board.


Said tooling could be "a text-based, email-based patch system that can 
then also be represented in a way that developers who have grown up in 
the last five or ten years are more familiar with," she added.


...

Should it migrate toward something more like, say, issues and pull 
requests on the Microsoft-owned GitHub? “I’m not saying that there will 
be a move in any time that I can see  my crystal ball’s broken  but I do 
think there needs to be expansions in the way people can enter that 
workflow,” said Novotny.


“It is a fairly specific workflow that is a challenge for some newer 
developers to engage with. As an example, my partner submitted a patch 
to OpenBSD a few weeks ago, and he had to set up an entirely new mail 
client which didn’t mangle his email message to HTML-ise or do other 
things to it, so he could even make that one patch. That’s a barrier to 
entry that’s pretty high for somebody who may want to be a first-time 
contributor.”"


https://www.theregister.com/2020/08/25/linux_kernel_email/



Re: Article OpenBSD: Not Free Not Fuctional and Definetly Not Secure and BSD, the truth blog

2020-05-28 Thread Frank Beuth

On Thu, May 28, 2020 at 01:27:15PM +0200, infoomatic wrote:

I just don't get it why some people put so much energy into bashing a
free product instead of just ignoring it if they really hate it. The
time would have been better spent on supporting/improving OpenBSD or
another project.


OpenBSD has mystique, a bunch of brilliant-but-prickly guys building a 
super-secure OS for their own use, everyone's heard of it but few 
actually use it, "ooh OpenBSD, that's hardcore." In a 
systemd-and-Microsoft world it starts to look something like the Man in 
the High Castle of operating systems, which is a tempting target for 
those who like the comfort of the majority.


Release poster idea: "The Pufferfish in the High Castle"



Re: OpenBSD sysupgrade rocks

2020-05-20 Thread Frank Beuth

On Wed, May 20, 2020 at 02:07:27PM -0400, Chris Bennett wrote:

Please don't beg for features.
That's very irritating and wastes everyone's time.

Please don't ask for features, once again.
Really, I mean it. Don't ask for features!


How about a counterpart to `sendbug` called `requestfeature`, which is 
an alias to `fortune` run with a file consisting of Theo's snarkiest 
remarks?




Re: Why isn't src included with OpenBSD? (documentation)

2020-05-18 Thread Frank Beuth

On Mon, May 18, 2020 at 11:10:59AM -0600, Theo de Raadt wrote:

People too young to have grown up with Unix need this sort of
documentation.  We can't live on man pages alone.


YES WE CAN.


Proposed release poster design:

Puffy with puffed out cheeks & paper sticking out of his mouth.

Headline: "Man pages are all you need to live!"

Alternate headlines:
"We *can* live on man pages alone!"
"Man pages: a complete breakfast!"
"Man pages: they're delicious and nutritious!"



Re: Managing multiple OpenBSD systems with a single base install

2020-03-26 Thread Frank Beuth

On Wed, Mar 25, 2020 at 09:28:52PM -0400, Demi M. Obenour wrote:

I am working on an OpenBSD-based QubesOS TemplateVM, and have run
into a few problems.


I don't have answers to your questions, but that sounds like an 
amazingly good and useful project and I wish you all the best in making 
it happen!




Re: Web documentation available offline by default?

2020-03-04 Thread Frank Beuth

On Tue, Mar 03, 2020 at 10:15:31AM -, Stuart Henderson wrote:

On 2020-03-02, Peter N. M. Hansteen  wrote:

I was thinking of the probably quite unlikely event that somebody who wants this
comes up with an actually reproducible way that could be turned into an 
otherwise
unremarkable make target.


From experience with other generated files: it won't get used by
everyone who updates the faq, meaning that it's another thing that
somebody has to watch out for and fix it.

IMHO the only way to fix this is to convert the faq to some other
format that is used to generate a variety of output files (such that
the html files aren't stored in the repository, only the "input"
files, so there's no chance of getting it wrong). And *that* has
enough implications that I don't think it will work well either.


You're right, but I wish you weren't!



Re: Web documentation available offline by default?

2020-02-27 Thread Frank Beuth

On Fri, Feb 28, 2020 at 07:24:50AM +0100, Ingo Schwarze wrote:

Hi Frank,

Frank Beuth wrote on Fri, Feb 28, 2020 at 04:22:27AM +:


Is the web documentation (FAQ etc) included in the base system by
default anywhere,


No it isn't.

I offered some years ago to translate the FAQ from HTML to mdoc(7)
and to include it in /usr/share/man/faq/ such that it would become
available for both -current and -stable both online and offline
without additional maintenance effort just like any other documentation
and such that it would automatically be included in apropos(1)
searches, but the proposal was rejected because the developers who
actually maintain the content of the FAQ consider it easier to
maintain in HTML than in mdoc(7) format.

We don't want to lose the valued contributions of those developers
who actually spend all the work maintaining the FAQ or make their
work any harder than it is now.


Thanks. Too bad the mdoc idea failed!



Web documentation available offline by default?

2020-02-27 Thread Frank Beuth
Is the web documentation (FAQ etc) included in the base system by 
default anywhere, or do we have to pull it from CVS manually?




Re: Trusted Boot with OpenBSD

2020-02-26 Thread Frank Beuth

On Mon, Feb 24, 2020 at 03:22:28PM +0100, Julius Zint wrote:

boot(8) supports the machine specific command "tpm". This allows a
user to:

1: read the current contents of the Platform Control Registers (PCR)
  with the "pcr" parameter

  machine tpm p[cr]

2: seal a user supplied secret to the current PCR values and store it
  in the second block on a disk, that can be altered via a parameter.
  WARNING: If there is any other data in this block, it will be
  overwritten without asking again.

  machine tpm s[eal] secret [DiskNumber]

3: unseal a previously sealed secrent and display it to the user. This
  command just reads the second block of the disk that can be
  specified by the user and unseals it via the TPM

  machine tpm u[nseal] [DiskNumber]


I hope you are enjoying your (well-earned) vacation.

I can't tell from the instructions how the FDE encryption key is stored 
-- do we manually seal it to the TPM and then manually unseal and 
copy/paste it every time we boot? Or is it assumed the user will write a 
script to handle this -- a script which itself will have to be measured 
by the TPM?




Re: Full disk encryption including /boot, excluding bootloader?

2020-02-18 Thread Frank Beuth

On Tue, Feb 18, 2020 at 08:05:29AM +0100, Paul de Weerd wrote:

On Tue, Feb 18, 2020 at 05:12:25AM +, Frank Beuth wrote:
| Yes, it's a cool way to combine things to get unexpected functionality.
| I haven't dug into the bootloader much... is there a reasonably easy way
| to get the USB-stick-bootloader to boot the hard drive partition by
| default?

Best way to dig into the bootloader is by starting at its fine manpage
which you can read online at http://man.openbsd.org/man8/amd64/boot.8

The quick answer is `echo 'boot sr0a:/bsd' > /etc/boot.conf` (on the
USB-stick's root filesystem).


Thanks!



Re: Full disk encryption including /boot, excluding bootloader?

2020-02-17 Thread Frank Beuth

On Mon, Feb 17, 2020 at 06:44:25PM +0100, Paul de Weerd wrote:

On Mon, Feb 17, 2020 at 01:35:38PM +, Frank Beuth wrote:
| > | This way the evil maid would have nothing to tamper with.
| >
| > Note that with this approach, a default OpenBSD install to your
| > machine will still install a bootloader on the physical disk inside
| > your machine.  It's then on you to NOT use that.
|
| That's a heck of a hack!

Not sure how you mean that - I don't think it's that much of a hack,
mostly an interesting side-effect of how the bootloader works in
general.  Taken in combination with a "normal" install to removable
media, you get basically exactly what you want at no additional cost.

Note that you don't have to do a full (or even minimal) install, if
all you really want is use the bootloader on the removable media.
It's just the easiest way to prepare it that I know of.  Besides, if
you do a 'normal' install, you have a convenient 'live' or 'rescue'
system to carry around with you whenever you go: I've got one of these
on my keychain :)


Yes, it's a cool way to combine things to get unexpected functionality.
I haven't dug into the bootloader much... is there a reasonably easy way
to get the USB-stick-bootloader to boot the hard drive partition by
default?



Re: Full disk encryption including /boot, excluding bootloader?

2020-02-17 Thread Frank Beuth

On Mon, Feb 17, 2020 at 04:09:57PM +0100, Julius Zint wrote:



I'm not really in a position to reflash my machine but I would still be
curious for details.


There is no need to reflash your firmware if the system has a integrated
and supported TPM 1.2 chip.

The prototype uses a Static Root of Trust for Measurment (SRTM) approach
where the Chain of Trust is extended from a small immutable firmware part
up to boot(8). Every component in the boot chain is responsible for measuring
the components, that it hands control over the system. Measuring just means
calculating the hash and sending it to the TPM. The following example is the
Chain of Trust from my test system Lenovo Thinkpad X240 with OpenBSD.

1: Core Static Root of Trust for Measurment (C-SRTM) (immutable part of the 
Firmware)
2: Firmware (including OptionROMS)
3: MBR (mbr(8))
4: PBR (biosboot(8))
5: boot(8) (residing in the softraid(4) metadata when FDE is enabled)

I changed the mbr(8) and biosboot(8) to support measuring their next component.
Because there is very little available space left in the 440 byte of the mbr(8)
startprogram, you have to choose between CHS and measurement support at compile 
time.

boot(8) got support via a machine specific command to seal and unseal a secret 
of
your choosing to any drive. Sealing and unsealing means encrypting/decrypting
data depending on the state of the Platform Control Registers (PCR). PCRs are in
the TPM NVRAM and store the measurements.

With the laptop being in a trusted state, you can seal a secret and store it on 
a
usb drive. When you want to verify, that the software components are unchanged, 
you
plug in the usb drive and unseal the secret. If the output shows the correct 
secret
and you were the only person knowing it, than there is a very high chance that 
the
early boot components are unchanged.

Some feedback from the OpenBSD community on this would also be appreciated. Are 
there
enought people interessted in a Trusted Boot with OpenBSD?


That's amazing if you can get it to work without reflashing. Are you
then sealing the disk encryption key?

Unfortunately I have to be a bit conservative with my laptop, but I
would be quite interested in testing this once it's
near-production-ready.



Re: Full disk encryption including /boot, excluding bootloader?

2020-02-17 Thread Frank Beuth

On Mon, Feb 17, 2020 at 11:56:24AM +0100, Paul de Weerd wrote:

But you can already do this.  If your machine supports booting from
USB, you can do a minimal install to a USB stick (using FDE, if you
want).  Now you have a portable OpenBSD environment you can boot on
any system capable of booting from USB (and supporting the same kernel
architecture).

What you can also do with this USB stick is use its bootloader to boot
the OS stored on the disk inside your machine (FDE encrypted or not).

I've used this to fix up installs gone sour on my machines in the
past.  Works a treat.  I don't use it to prevent the evil maid case
you describe though, but I think it would work just fine.

| This way the evil maid would have nothing to tamper with.

Note that with this approach, a default OpenBSD install to your
machine will still install a bootloader on the physical disk inside
your machine.  It's then on you to NOT use that.


That's a heck of a hack!



Re: Full disk encryption including /boot, excluding bootloader?

2020-02-17 Thread Frank Beuth

On Mon, Feb 17, 2020 at 11:13:27AM +0100, Julius Zint wrote:

I recently finished my masterthesis that solves this problem by including
the Trusted Platform Module (TPM) in the bootprocess of OpenBSD.

It extends the Chain of Trust up to boot(8) and allows you to seal a
secret of your choice to the platform state.

To check wether the unencrypted bootcomponents got tampered with, you
can unseal and verify the secret to ensure that the contents of the
MBR, PBR and boot(8) are unchanged.

it is not exactly the solution you were looking for but it should solves
the problem that you describe. Does this sound like something you were
willing to try and does your machine have a TPM 1.2 Chip?


That sounds absolutely fascinating. Are you familiar with the Heads
firmware? How is your approach different?

I'm not really in a position to reflash my machine but I would still be
curious for details.



Re: Full disk encryption including /boot, excluding bootloader?

2020-02-17 Thread Frank Beuth

On Sat, Feb 15, 2020 at 12:22:02PM +0100, no@s...@mgedv.net wrote:

>depends what you want to achieve, but my recommendation is booting from
USB
>and mount encrypted root from the HDD.
>you can safely remove the usb key after root mount and all your

configs/etc

>files are used from the encrypted storage.
>this ensures 2 things: bootloader + kernel on USB boot media cannot be
>attacked during system uptime and all bytes on disk are encrypted.
>another advantage is, you don't need (to type, write down or remember)

any

>passphrases but can use strong random data for crypto payload/keys.
>

How do you do this on OpenBSD?

@frank: https://www.openbsd.org/faq/faq14.html#softraidFDEkeydisk


That's telling me how to use a keydisk -- how to put the softraid FDE
encryption key material on a USB disk.

If an evil made came by and got access to my machine, they would still
be able to tamper with the bootloader code to harvest the FDE password
when I returned.

I want to put the whole bootloader (including the code used to decrypt
the softraid-FDE-encrypted root-partition-containing media) on a USB
disk.

This way the evil maid would have nothing to tamper with.



Re: Full disk encryption including /boot, excluding bootloader?

2020-02-14 Thread Frank Beuth

On Thu, Feb 13, 2020 at 01:31:43PM +0100, no@s...@mgedv.net wrote:

depends what you want to achieve, but my recommendation is booting from USB
and mount encrypted root from the HDD.
you can safely remove the usb key after root mount and all your configs/etc
files are used from the encrypted storage.
this ensures 2 things: bootloader + kernel on USB boot media cannot be
attacked during system uptime and all bytes on disk are encrypted.
another advantage is, you don't need (to type, write down or remember) any
passphrases but can use strong random data for crypto payload/keys.



How do you do this on OpenBSD?



Re: How to hide my server's IP?

2020-02-03 Thread Frank Beuth

On Mon, Feb 03, 2020 at 10:46:03AM +0100, Janne Johansson wrote:

The attacker would thereby be able to find your IP
address.



By the time your opponent is running code on your server, this piece of
information is probably the least interesting part of the whole puzzle.


Not at all. For people running hidden/onion/i2p services (as I assume
the OP is doing) being able to hide the IP from an attacker can be very
important. If you run a server for the Hong Kong protests, you
probably don't want the authorities to be able to find out which
apartment block to raid, even if they find an exploit in the software.



Re: How to hide my server's IP?

2020-02-02 Thread Frank Beuth

On Sun, Feb 02, 2020 at 09:24:20PM +, Arthur Wayside wrote:

Hello.

Say I run a websapp inside a chroot and someone manages to hack it and gain 
shell access. Can I then somehow hide my server's IP from the likes of ifconfig?


If you want to hide your public IP from a particular application for
security reasons, the only way I know of to reliably do this is to run
that application on a physically separate server or inside a virtual
machine, and then bridge/port forward traffic to the VM. This way the
application (and any system components it has access to) can only ever
know the internal IP address of the server or virtual machine.

Otherwise it would be possible for an attacker to, for example, hack
your webapp to have it phone home to some external server controlled by
the attacker. The attacker would thereby be able to find your IP
address.

A less-secure approach would be a local firewall that only permits
outgoing network access to processes run by a specific user (which is
NOT the user account of your webapp) and then have the forwarding
handled by an application running under that user account. (this is the
approach taken by the TAILS Linux+Tor live USB)



Re: Question about marketability of OpenBSD Laptops

2020-01-26 Thread Frank Beuth

On Sat, Jan 25, 2020 at 07:26:35PM -0500, Chris Bennett wrote:

Try this. Put OpenBSD on a USB stick. Then try to get ANYONE to boot it
on their laptop/desktop. I gave up after about 25 tries over the years.

Next, try this. Give away a few laptops with OpenBSD already installed
for free. Check back with these people 3 months later. You won't find a
single one with OpenBSD still installed unless they just stuffed it in a
closet.


If I was going to do it, I would include at least 5-10 hours of
one-to-one training (how to use & set everything up, etc) then regular
check-backs at monthly intervals.

In other words, think of it more like a consulting arrangement (which
others already offer) than a hardware give-away or sale.

The reason is that -- in my experience -- the most important part of
computer security is the part which exists between the computer and the
chair.

If the end user has no clue, they will find a way to fuck up even
OpenBSD. Or they will just not use it.

You have to work out how to make OpenBSD a better solution than whatever
it is they currently have... then ensure they understand the situation
enough to use the setup securely.

OpenBSD won't stop you from clicking on a phishing email and entering
your credit card.



Re: Userland PCI drivers possible in OpenBSD?

2020-01-10 Thread Frank Beuth

On Fri, Jan 10, 2020 at 07:23:26PM -0500, gwes wrote:

On 1/9/20 10:58 PM, Joseph Mayer wrote:

Maybe this topic is better suited for tech@, you tell:

Is there some way I can implement PCI drivers in userland in OpenBSD?

Is there any reason not to write a conventional device driver and
build an OS including that driver?


You and/or the original poster may want to look at MirageOS: https://mirage.io/

Depending on the application, the custom-unikernel approach may offer an
otherwise-impossible combination of performance and security.



Re: perl popularity inside openbsd community? (Re: Suggestion: Replace Perl ...)

2020-01-01 Thread Frank Beuth

On Wed, Jan 01, 2020 at 03:30:44PM +0100, Marc Chantreux wrote:

why is this ? return is the perl yield. the only difference is that the
"exhausted" situation is on your own. so basically:

   def count_from(x):
   while True:
   yield x
   x = x + 1

   naturals = count_from(0)
   print(next(naturals))
   print(next(naturals))
   print(next(naturals))
   print(next(naturals))

is written in perl

   use experimental 'signatures';
   use feature 'say';

   sub count_from ($x) { sub { $x++ } }
   sub NEXT ($generator) { $generator->() }
   my $naturals = count_from 0;

   say NEXT $naturals;
   say NEXT $naturals;
   say NEXT $naturals;
   say NEXT $naturals;






* perl were about unix culture, mailing lists and so on: they setup a
 confortable cocoon to work together and this cocoon became an echo
 chamber when the other communities started to use third party services
 like stack overflow.


https://github.com/drathier/stack-overflow-import


* the python community was unfair comparing the langages (using ugly
 perl code and nice python counterparts). instead of taking time to
 explain all the biases, perl community repetedly asserted that the
 authors of those article were incompetents and gone away.


Not sure about anyone else, but comparing the Python vs Perl example you
gave above, I would still say Python is the nicer-looking language.



Re: Suggestion: Replace Perl with Lua in the OpenBSD Base System

2020-01-01 Thread Frank Beuth

On Wed, Jan 01, 2020 at 10:29:53AM +, e...@isdaq.com wrote:

But I don't want deeper point to get missed -- which is that if eecd
doesn't like the idea of regulating what the programmer can do, then the
programmer has to have the skills to safely write unsafe code.


no you're belying the point: the good programmer regulates himself 
while you

want to police everything and everyone else to compensate for your own
shortcomings


I don't think I suggested anywhere that I want to police anyone else. I
largely agree with what you write with respect to self-regulation.
However, I'm not sure that ranting about it on misc@ is the most
effective way to make positive progress in the desired direction.



Re: Suggestion: Replace Perl with Lua in the OpenBSD Base System

2020-01-01 Thread Frank Beuth

On Tue, Dec 31, 2019 at 11:56:46PM -0700, Bob Beck wrote:

read fucking code.  change fucking things. send some fucking diffs. get
fucking yelled at. learn from your fucking mistakes.  show some fucking
passion.  filter fucking misc@ and all this useless bleating into the
toilet.

none of us have time to spoon feed you in some “boot camp”

there are two types of programmers. the self taught, and the hopeless. it
is your job to turn yourself from the hopeless to the self taught.

shut up and fucking hack.


Well put.

But I don't want deeper point to get missed -- which is that if eecd
doesn't like the idea of regulating what the programmer can do, then the
programmer has to have the skills to safely write unsafe code.






On Tue, Dec 31, 2019 at 23:50 Frank Beuth  wrote:


On Wed, Jan 01, 2020 at 04:00:37AM +, e...@isdaq.com wrote:
>rather than the programmer being responsible for
>writing unsafe
>code we need to regulate what the programmer can do just like we need to
>regulate what the community can say, do, see, and think.

where do I sign up for OpenBSD write-perfect-C-code programmer training
bootcamp?






Re: Suggestion: Replace Perl with Lua in the OpenBSD Base System

2019-12-31 Thread Frank Beuth

On Wed, Jan 01, 2020 at 04:00:37AM +, e...@isdaq.com wrote:
rather than the programmer being responsible for 
writing unsafe

code we need to regulate what the programmer can do just like we need to
regulate what the community can say, do, see, and think.


where do I sign up for OpenBSD write-perfect-C-code programmer training 
bootcamp?



Re: regression tests (was: OpenBSD Errata: December 11th, 2019 (ldso))

2019-12-15 Thread Frank Beuth

On Sat, Dec 14, 2019 at 11:39:57AM +0100, Claus Assmann wrote:

On Sat, Dec 14, 2019, Frank Beuth wrote:


OpenBSD doesn't have unit tests (or if they are, they're not in the main


Hmm, what about src/regress/ ?


Ah, that's what I was looking for. Not sure how I missed that.



Re: OpenBSD Errata: December 11th, 2019 (ldso)

2019-12-14 Thread Frank Beuth

On Wed, Dec 11, 2019 at 01:51:18PM -0500, T.J. Townsend wrote:

Errata patches for ld.so have been released for OpenBSD 6.5 and 6.6.

ld.so may fail to remove the LD_LIBRARY_PATH environment variable for
set-user-ID and set-group-ID executables in low memory conditions.


The security advisory connected with this bug indicates the patch was
published within 3 hours of reporting: 
https://www.openwall.com/lists/oss-security/2019/12/11/9

OpenBSD doesn't have unit tests (or if they are, they're not in the main
source tree). How does the project ensure that such wonderfully quick
fixes don't introduce new bugs?



Re: Skype alternatives for OpenBSD

2019-11-04 Thread Frank Beuth

On Sun, Nov 03, 2019 at 11:12:48AM +, Andrew Luke Nesbit wrote:

On 03/11/2019 10:55, Frank Beuth wrote:

Not sure about the original poster but I would be interested in
any end-to-end encrypted video/audio/chat programs that are
available.


Have a look at Tox.  It might work out for you on a technical level.


Are Tox and/or Matrix available on OpenBSD? I only see a FreeBSD version
of Tox, while 'matrix' is a fairly generic name so hard to say.



Re: Skype alternatives for OpenBSD

2019-11-03 Thread Frank Beuth

On Sun, Nov 03, 2019 at 04:51:48PM +1000, Stuart Longland wrote:

Do you need any video conferencing software (i.e. the group running the
online class is willing to switch to whatever you can get working?), or
do you specifically need Skype?


Not sure about the original poster but I would be interested in any
end-to-end encrypted video/audio/chat programs that are available.



Re: A promotional idea (related to quantum computing / hacking)

2019-10-26 Thread Frank Beuth

On Sat, Oct 26, 2019 at 02:53:42PM +0800, Jyri Hovila [Turvamies.fi] wrote:

Maybe OpenBSD could profile itself as *the* OS with all crypto related stuff is 
handled using post-quantum cryptography?


I don't think OpenBSD wants to "profile itself" as anything.

Are post-quantum algorithms well reviewed and stable enough to be worth
using as defaults for OpenBSD full disk encryption, OpenSSH,
LibreSSL...?

Do you or anyone else have the expertise to implement them?



Re: On blindly running code

2019-10-18 Thread Frank Beuth

On Fri, Oct 18, 2019 at 01:20:33PM +0100, cho...@jtan.com wrote:

Frank Beuth writes:

On Fri, Oct 18, 2019 at 11:54:18AM +0100, cho...@jtan.com wrote:
>Virtualisation is not a panacea. I have managed to achieve data loss through 
destructi
ve actions taken within a "safe" virtualised sandbox.

How did you manage that feat?


Basically assuming "safe" then taking actions to subvert that, namely
mounting an SMB share within the VM. rm(1) does not discriminate. My
own fault obviously but it's notable that the "virtual environment ==
safe" assumption was shattered so effectively, so easily, and by
actions which in most circumstances would be benign.


Poking holes in parachutes has been known to impair their function,
yes...



Re: Requesting vi tips

2019-10-18 Thread Frank Beuth

On Fri, Oct 18, 2019 at 03:12:37PM +0100, cho...@jtan.com wrote:

Alternatively is there something that would make vi do it on the fly, or
something akin to emacs' C-q or vim's gq. Although I appreciate the fact
that vi doesn't try to be clever.


1) select all text in visual mode (e.g with V, then gg)
2) :!fmt -w 72

disclaimer: vi is aliased to vim on my system so apologies if this
doesn't work



Re: On blindly running code

2019-10-18 Thread Frank Beuth

On Fri, Oct 18, 2019 at 11:54:18AM +0100, cho...@jtan.com wrote:

Virtualisation is not a panacea. I have managed to achieve data loss through destructive 
actions taken within a "safe" virtualised sandbox.


How did you manage that feat?



If the only thing that can demonstrate what a piece of code does is to run it 
blindly, rather than to work it out by reading and study, then the code is 
faulty and should be replaced. I expect the code I use to be in this state 
before I will even begin to trust its documentation because if the developer 
doesn't understand what it does how can his explanation be at all enlightening? 
Executing code in a test environment should only be to *verify* the assumptions 
and calculations you have *already made*.


In the world of malware analysis, running code blindly (in a virtual
machine) in order to figure out what it does (by comparing "before" and
"after" snapshots) is standard operating procedure.

(standard operating procedure doesn't necessarily make it a good idea,
but it is what it is)



Re: OpenBSD Project

2019-07-21 Thread Frank Beuth

On Sun, Jul 21, 2019 at 10:37:40AM -0600, Theo de Raadt wrote:

I'm mentioning this to highlight the false pattern of
believing "democracy is a required component" in a world where people
forget the most dominant models in all industries are a mix of
fascism, monarchies, or well ... plutocracy.

And what OpenBSD is doing is industry, plain and simple.


So you're saying OpenBSD is a... theocracy?



OpenBSD's FBI file

2019-07-21 Thread Frank Beuth

https://www.muckrock.com/foi/united-states-of-america-10/foia-fbi-openbsd-70084/

Earlier this year I FOIAed the FBI for details on allegations of backdoor installed 
in the IPSEC stack in 2010, originally discussed by OpenBSD devs 
(https://marc.info/?l=openbsd-tech=129236621626462 …) Today, I got an 
interesting but unexpected responsive record: 
https://www.muckrock.com/foi/united-states-of-america-10/foia-fbi-openbsd-70084/ … 
#FOIAfriday

The record I was provided by the FBI was created Sept. 2002, and details a 
separate investigation into an operation tiled 'OPERATION 0DAY COMPUTER 
INTRUSIONS': 
https://cdn.muckrock.com/foia_files/2019/07/19/Ecd74aeb090e009e1ede26e1a0fe860c184bb6797_Q52218_R348013_D2256726.pdf
 …

To my knowledge there are no other public agency records available regarding 
this.

There are a lot of redactions here, but it looks like the focus here might have 
been an exploit that lead also to the following OpenSSH vuln: 
https://web.archive.org/web/20080622172542/www.iss.net/threats/advise123.html …

"OpenBSD was compromised through the internet host http://cvs.openbsd.org  or 
http://ftp.openbsd.org ,.. [REDACTED] claimed on IRC channel [REDACTED] which he connects 
to from internet hosts in Australia, to have committed the hack."

https://twitter.com/RooneyMcNibNug/status/1152329067707928583



Re: Evernote Alternative?

2019-06-28 Thread Frank Beuth
git init a folder, keep your notes as plain text files in that folder, and use 
standard git commands to sync changes everywhere?


On Fri, Jun 28, 2019 at 01:58:34PM -0400, Christopher Turkel wrote:

Is there a how to about to use git for this? It sounds awesome.

On Friday, June 28, 2019, Chris Humphries  wrote:


Hrm, I'm not finding a leannote port available for OpenBSD. Is it
available in an alternate location.

http://openports.se/search.php?stype=folder=leannote

The screenshots and features look nice.

-Chris

On Fri, Jun 28, 2019 at 05:06:23PM +, drozdow wrote:
> leannote / just use git
>
> Inviato da ProtonMail mobile
>
>  Messaggio originale 
> On 28 giu 2019, 1:32 AM, Chris Humphries ha scritto:
>
> > Hello,
> >
> > I have been looking to migrate off of Evernote for a while, and now
> > that my daily driver is OpenBSD, I am more motivated to migrate from
> > Evernote to something else (nixnote2 isn't a port and looks to be a
> > pain to make a port of).
> >
> > I keep a lot of my brain in Evernote, and having a replacement is a
> > big productivity boost for me. I mainly want a way to categorize notes
> > into categories/labels/notebooks, be able to view all notes in that
> > category/label/notebook, and be able to search all notes.
> >
> > If I could also access that information from a mobile device, that
> > would be great but not required.
> >
> > I did a lot of searching and the only thing I see that comes close
> > that a port exists for is Zim, which looks like it could work on most
> > fronts.
> >
> > Have you made a transition from Evernote/Onenote before? If so, what
> > did you do?
> >
> > Thank you!
> >
> > --
> > Chris Humphries 
> > [5223 9548](tel:52239548) E1DE DE87 F509 1888 8141 8451 6338 DD29






Re: Ansible install Re: Reboot and re-link

2019-06-24 Thread Frank Beuth

On Mon, Jun 24, 2019 at 10:59:44AM +0200, David Sastre wrote:

I would not consider ansible as the right tool to provision a system
from scratch (as in PXE booting, etc...).
Ansible is better used on a system you can connect to using SSH and
perform actions as required, with or without doas, as you surely know.
You don't mention cloud providers/VPS you are trying to bootstrap
OpenBSD to, but the way I'd tackle this situation, if I have
understood your use case correctly, is as follows:

- Find out if the specific cloud provider is supported by packer [1]
(packer itself can be run in OpenBSD[2]).
 Custom builders can be written, but might be overkill for the task at hand.
- If the answer is yes, create a template to bootstrap an OpenBSD image.
 You can find many examples online[3]. The specifics of the packer
template vary depending on the cloud provider,
 but usually you can bootstrap the system from an ISO (or an existing
AMI, if in AWS), and finish provisioning
 the configuration using ansible.


And what if the answer is no? You didn't mention that :)

Yes, Ansible is not really the right tool for installing new images onto 
machines or re-imaging server. Yes, Packer and Terraform (both from the same 
company) are superb and wonderful ways of managing machines on AWS/Azure/the 
rest of the API-enabled IaaS crowd.


However great the Big Cloud providers are, though, sometimes they are not 
suitable for a project, and instead one is left in the position of bartering 
a cow in exchange for a VPS instance at HostElbonia, where you're lucky if the 
API is RFC 2549 compliant.


And in general, one of the things I like most about OpenBSD is the design for 
simplicity, emphasizing standard, boring interfaces that are extremely 
reliable and which don't require the "hot new shiny object" du jour. 

So while yes, automated provisioning of AWS over the API is an option, as is 
setting up the Linux VPS as a hypervisor running OpenBSD... it doesn't quite 
feel right.


It sounds like a custom bsd.rd with auto_install.conf, dropped onto the /boot 
partition by Ansible (or some other script or management tool!) is the way to 
go for this. 

Ihave a few other projects to deal with, but it is on my to-do list, and if I 
come up with something potentially useful to others then I will try and write 
it up in some form.




Re: Ansible install Re: Reboot and re-link

2019-06-24 Thread Frank Beuth

On Mon, Jun 24, 2019 at 11:43:36AM +0300, Gregory Edigarov wrote:
I don't want to re-open the hostilities, but installing OpenBSD via 
Ansible is very relevant to my interests. Previously discussed on 
this list was a very roundabout approach using Qemu -- is there a 
better way now?


it's all easy given it is some IaaS provider, just use terraform to 
create the ground, (terraform could also be used to upload keys, and 
do some preconfiguration) then call ansible.


Terraform looks great, but while some of the providers I need to support are 
listed (https://www.terraform.io/docs/providers/index.html ) that's not true of 
all of them, and probably never will be. In general, being bound to Big Cloud 
(AWS / DigitalOcean / et al) is not desirable.


On top of this, my objective for this project is to support the most generic 
and standardised possible interface ("image with the provider's web interface 
and SSH in after") rather than develop a system that implicitly encourages 
lock-in.


Nevertheless looks like a superb tool if it fits.



Re: Ansible install Re: Reboot and re-link

2019-06-23 Thread Frank Beuth

On Sun, Jun 23, 2019 at 10:49:22AM +0300, cho...@jtan.com wrote:

Frank Beuth writes:




You go ahead and continue to trust your VPS without taking any care to
consider where your software comes from.

It's choices like that which make "hardening" even be a thing. Have you
considered _not_ building a system on a foundation made of cheese?


Of course, but those are the constraints I have to deal with.

Naturally a dedicated bare-metal server would be preferable, but that is not 
always possible. Given the tremendous popularity of VPS hosting, it does seem 
like I am not alone.


Just because there is risk on the back-end of the system does not mean we 
should be careless in other respects.




Re: Ansible install Re: Reboot and re-link

2019-06-22 Thread Frank Beuth

On Sat, Jun 22, 2019 at 03:06:30AM +0100, Andrew Luke Nesbit wrote:

On 21/06/2019 19:02, Frank Beuth wrote:

I don't want to re-open the hostilities, but installing OpenBSD via
Ansible is very relevant to my interests.


I feel exactly the same way and am surprised that Ansible caused
hostilities.  Can you send me a link to the thread where this happened
please?  I want to know why, i.e., pros and cons.


It doesn't look to me like Ansible as such caused any trouble, it was someone's 
use of Ansible in an unsupported way (and probably many other configuration 
choices), leading to further problems, and then people got angry.


For details search the misc@ archives for "Reboot and re-link" (the subject 
line), things got spread across multiple threads:

https://marc.info/?l=openbsd-misc=2=1=Reboot+and+re-link=t



Re: Ansible install Re: Reboot and re-link

2019-06-22 Thread Frank Beuth

On Sat, Jun 22, 2019 at 10:29:22PM +0300, cho...@jtan.com wrote:


Ansible is not the correct tool for this job; it can only configure and
maintain an _extant_ system.

None of the recent plethora of configuration management tools have
considered the scenario *before* an operating system has been
installed. All of them expect the server to exist and for secured
communication channels to have been established between it and the
master control system before they are operable.


That's the interesting thing in my case (at least)... the system *IS* already 
extant!


It has a nice shiny new Ubuntu/Debian/Fedora/centOS install that has just been 
imaged onto it using the hosting provider's default tooling, and SSH is already 
configured. (without blindly saying "yes" to the unexpected-fingerprint prompt)


Normally in this situation one would just use Ansible to harden the default 
Linux install and configure whatever applications are needed. But in this case 
I feel like hardening the Linux install even more, by replacing it with OpenBSD 
:)


Maybe I'm wrong, but it seems like if this problem were well-solved then it 
would make easier to use OpenBSD in many more applications and situations.



FWIW I'm working on-and-off on a tool which specifically automates
*that* problem (build a new server/vm/chroot with zero human
interaction so Ansible et al. can subsequently and safely take over)
but what I've released so far is alpha quality at best.

Conveniently if you're only targetting OpenBSD then it's entirely
useless because, provided you can use PXE*, the OpenBSD developers have
already solved it.

Without Ansible.

Matthew

[*] The autoinstall/siteXX.tgz/etc. solution provided by the OpenBSD
developers is very good but there are some questions I have around
integrity on a potentially untrusted network. However as I'm trying to
target more than just OpenBSD, and I don't trust any network, I've
simply abandoned the idea of using PXE in my own environments so I
haven't looked into the answers to them. YMMV.


I'd love to see your tool. PXE is mostly not available for this case (in 
general I am trying to target the most generic possible situation).




Re: Ansible install Re: Reboot and re-link

2019-06-22 Thread Frank Beuth

On Sat, Jun 22, 2019 at 10:28:53AM -0700, Lyndon Nerenberg wrote:


We are looking forward to that.  *However*, there is a lot to be
said for regularly re-installing your hosts from scratch.  This
ensures your installer scripts don't rot as host system "features"
accrete over time.  This is prone to happen when you Ansible- or
Puppet-manage servers.  Things get added, things get removed.  Often
you miss hidden dependencies that sneak in; you don't want to be
discovering those when you're trying to reinstall a production host
after a catastrophic failure.


Yes, and being able to Ansible-manage even the re-installation would make the 
whole process that much nicer :)




Re: Ansible install Re: Reboot and re-link

2019-06-22 Thread Frank Beuth

On Sat, Jun 22, 2019 at 04:41:47AM +0100, Andrew Luke Nesbit wrote:

On 21/06/2019 19:02, Frank Beuth wrote:

I don't want to re-open the hostilities, but installing OpenBSD via
Ansible is very relevant to my interests.


I feel exactly the same way and am surprised that Ansible caused
hostilities.  Can you send me a link to the thread where this happened
please?  I want to know why, i.e., pros and cons.


It's the parent thread of this one (look for subject line "Reboot and 
re-link").


The issue was not Ansible, just that the original thread poster got very angry 
with people.




Re: Ansible install Re: Reboot and re-link

2019-06-21 Thread Frank Beuth

On Fri, Jun 21, 2019 at 01:20:44PM -0700, Misc User wrote:


You could stick bsd.rd onto a bootable partition then point grub to it.
You could also disable password login for root and just use a key pair.
That way you wouldn't be sending the password encrypted (or at most only
giving it a password that is useless without console access, then run
'doas passwd' the first chance you get to eliminate even that vector).
That temp password could even be a long string of random junk so long as
you enter it twice.

You could copy bsd.rd and a copy of your pub key into /boot, or carve
out a new partition using some unused disk space.



Yes, the goal is a fully automated and unattended (but "stock," supported, and 
rage-free) install.


The process of spinning up a new machine should be "add the IP address to the 
Ansible hosts file, run the playbook" as opposed to "dig out VNC and mess about 
with everything and get interrupted by someone with something urgent and come 
back and try to remember where I was..."


This seems pretty close to doable:

Ansible ought to be capable of dropping the bsd.rd into /boot and adding the 
relevant lines to grub, then triggering a restart.


Creating partitions seems unnecessary if we can just get the sets via HTTP, 
yes? Resizing partitions post-install would add complexity.


The autoinstall(8) man page (https://man.openbsd.org/autoinstall ) is a little 
unclear on whether we need to build a custom dhcpd.conf if we are using a local 
auto_install.conf, however I assume the answer is "no".


(If "yes," then Ansible would need to get the MAC address from the server 
initially, build the dhcpd.conf, and put it in the bsd.rd before uploading...)


Since parameters such as root password, user's username, user password, user 
SSH key, etc should be configured in the Ansible playbook or ancillary files, I 
wonder if there is a way to have Ansible build a custom autoinstall.conf (using 
templates) and insert it into bsd.rd immediately prior to uploading.


For that matter I can't find any instructions for editing bsd.rd or adding 
files to it, did I miss a manpage somewhere?


(It's too bad supplying the file locally requires editing the image, it would 
be nicer to drop the file onto /boot and then pass the filename as an argument 
when booting...)




Re: Ansible install Re: Reboot and re-link

2019-06-21 Thread Frank Beuth

On Fri, Jun 21, 2019 at 12:36:22PM -0700, Misc User wrote:

I use PXE + install.conf + siteXX.tgz + siteXX-%hostname%.tgz for my
installs.  I also have an rc.firsttime to download and install the
required packages.


Thanks, but neither this nor the autoinstall suggestion seem applicable for my 
use case.


I am dealing with virtualized servers which usually start out as 
Ubuntu/Debian/Fedora images, then the hosting provider supplies the IP address 
and root password for a first-time SSH login. 

In many cases it is not possible to upload an ISO to be used as server 
installation media, and VNC consoles (if available) are often not even 
encrypted. (How would you feel about installing OpenBSD and then having your 
root password sent in plaintext at the very beginning?)


I realize installing OpenBSD under these constraints is rather like installing 
a ship in a bottle, but it seemed worth it to ask...




Ansible install Re: Reboot and re-link

2019-06-21 Thread Frank Beuth

On Wed, Jun 19, 2019 at 11:29:32PM +0200, Maxim Bourmistrov wrote:

Installing via NOT RECOMMENDED WAY(following upgrade65.html) - scripting on
steroides (ansible).


I don't want to re-open the hostilities, but installing OpenBSD via Ansible is 
very relevant to my interests. Previously discussed on this list was a very 
roundabout approach using Qemu -- is there a better way now?




Re: Block/allow outgoing traffic by user or application?

2019-02-25 Thread Frank Beuth

On Mon, Feb 25, 2019 at 12:31:42PM -, Stuart Henderson wrote:

I've not done much with ssh tun forwarding, but I have previously had
to run openvpn over TCP and didn't find that it really get in the
way in practice, even with connections over wifi. It would depend
on connection characteristics though.

The sshuttle documentation mostly talks about lack of feedback into
TCP's congestion control mechanism; that could be mitigated by
"regenerating" the TCP sessions on the tunnel endpoint, I think
it maybe possible to bodge this together using relayd's "forward
to destination". But I would only mess about with that if I had
tried it and was seeing things working poorly, rather than just
for the sake of maybe making things faster.


Alright, that seems reasonable enough. Thanks!



Re: Block/allow outgoing traffic by user or application?

2019-02-24 Thread Frank Beuth

On Sun, Feb 24, 2019 at 03:12:31PM +, Stuart Henderson wrote:

Basically I'm trying to say, if you wanted to do it the other way round
(pass by default, block certain traffic) you wouldn't be able to block
everything.

If you're trying to stop all possible paths something on the system
might use to exfiltrate information then this is important (for example
if ping(1) is available and you're not blocking ICMP, this could be used
even as non-root with ping -p).


I see. "If you're in a situtation that requires blocking everything, then you 
should block by default" seems logical enough.


Not sure if there's any situation where you want to block by default but allow 
ICMP, that might be a bigger issue.



I had no idea there was such a thing as SSH tun forwarding, thanks for
telling me about it! :)


A useful addition to the toolkit :)


Do you know how (or how well!) it handles the performance issues associated 
with TCP-over-TCP? e.g

http://sites.inka.de/bigred/devel/tcp-tcp.html
https://unix.stackexchange.com/questions/34499/are-there-disadvantages-in-ssh-tunneling

apropos:
https://github.com/sshuttle/sshuttle



Re: Block/allow outgoing traffic by user or application?

2019-02-24 Thread Frank Beuth

On Sun, Feb 24, 2019 at 09:56:12AM -, Stuart Henderson wrote:

PF 'user' should do the trick. Note: it only works for TCP/UDP but for
this you should be able to do something like

block all
pass inet proto tcp to 192.0.2.1 port 22 user sshtunnel


Thanks. You say "only works for TCP/UDP", what other things should I be aware 
of? ICMP?



However if possible I would suggest either ssh tun forwarding or a VPN.
ssh socks forwarding is only for TCP which might be a bit restrictive,
plus you'll need special setup for applications with socks that you won't
need with tun forwarding or VPN.


I had no idea there was such a thing as SSH tun forwarding, thanks for telling 
me about it! :)




Re: Block/allow outgoing traffic by user or application?

2019-02-24 Thread Frank Beuth

On Sun, Feb 24, 2019 at 09:09:06AM +0100, Denis Fondras wrote:

On Sun, Feb 24, 2019 at 01:43:08PM +0700, Frank Beuth wrote:

Is it possible to restrict network access on a per-user or per-application
(rather than per-port) basis?

pf does not seem to have any capability to do this, maybe I missed something.



Don't know what you are aiming to do but pf rules have a "user" keyword.



Example: start an SSH tunnel with a SOCKS listener on localhost:8080, then 
ensure all outgoing application traffic uses the SSH tunnel instead of the 
shady public WiFi network I am connected to.


In this case, it looks like that can be done by creating a user `sshtunnel`, 
starting the SSH tunnel as that user, and then using the pf rule to block all 
egress traffic which is not either to localhost or from user `sshtunnel`.


Does that make sense?



Block/allow outgoing traffic by user or application?

2019-02-23 Thread Frank Beuth
Is it possible to restrict network access on a per-user or per-application 
(rather than per-port) basis?


pf does not seem to have any capability to do this, maybe I missed something.



Re: Research and OpenBSD: How can I help?

2019-02-20 Thread Frank Beuth

On Wed, Feb 20, 2019 at 09:16:04PM -0500, James Huddle wrote:

Personally, I envision a sort of "open source BIOS"
library in the distant future.  Something we jack in on jtag
if we have to.  There is no harm in *starting.*  Meanwhile,
my super productive Dell laptop can't keep me from wondering
what the SMM is doing during the SMI, while obsd or any other
OS sleeps.


There is Coreboot, but it's not a complete solution to the problem yet
- it does address SMM/SMI but as far as I can tell not necessarily on all 
 platforms,
- options for removing Intel ME/AMD PSP are limited, 
- and of course it does not cover e.g onboad ARM coprocessors, embedded 
 controllers, keyboard controllers, hard disk controllers which may be smart 
 enough to run a whole Linux kernel and edit your files behind your back 
 , etc...




Re: Research and OpenBSD: How can I help?

2019-02-19 Thread Frank Beuth

On Thu, Feb 14, 2019 at 04:22:05AM +, Paul Swanson wrote:

I have some general areas of interest, such as embedded
computing, but nothing is set in stone yet, so I thought it'd
be fun to hear from those in know about areas of priority need
within the OpenBSD community.

Are there particular problems that could benefit from new
ideas or solutions?


An area that I am personally interested in is running OpenBSD on fully 
open-source / binary-blob-free hardware: hardware where there is no proprietary 
firmware that could hide vendor backdoors, and ideally where even the design of 
the chip is available to the user for review.


The trouble is it's VERY hard to find "fully open" hardware, and the hardware 
which is known to exist (loongson, OpenPOWER, RISC V) is difficult to get, 
expensive or not very good, and (except for loongson) not supported by OpenBSD.




Re: Raspberry Pi support in 6.4

2019-01-19 Thread Frank Beuth

On Sat, Jan 19, 2019 at 04:21:50PM +0200, Mihai Popescu wrote:

Why not an AMD Opteron A1100 based board?


Because I haven't looked into it yet.

This all started because I'm on vacation in a major electronics hub and saw a 
Raspberry Pi at a local mall, thought it would be a fun project and 
want to get away from Intel ME/AMD PSP binary blob-istan.


Would love to have a totally open computer where all the code is auditable, 
and have it be small enough to pack into my carryon for the flight home...




Re: Raspberry Pi support in 6.4

2019-01-19 Thread Frank Beuth

On Fri, Jan 18, 2019 at 08:19:29PM +, Stuart Henderson wrote:

On 2019-01-18, Frank Beuth  wrote:

(misc got dropped?)


Yes, your mail was off-list so I replied off-list.


Ah, ok. Mea culpa, must have hit the wrong key.



Re: Raspberry Pi support in 6.4

2019-01-18 Thread Frank Beuth

On Fri, Jan 18, 2019 at 07:02:11AM +, Michael Joy wrote:
I'd be more than willing to a Pinebook for testing. I wanted one anyway. 


If I end up buying one, I'll buy one for you too :)



Re: Raspberry Pi support in 6.4

2019-01-17 Thread Frank Beuth

(misc got dropped?)

On Thu, Jan 17, 2019 at 04:28:05PM +, Stuart Henderson wrote:

> I'll take a look at that. Why would you prefer the PINE64 over the RBP?

Partly due to the improved storage/connectivity options (especially on
rockpro64) but largely because there seems a bit more developer interest
in them than in the rpi.


Is it binary-blob-free?

The Pinebook looks great, and a quick glance at the archives raises hopes that 
the answer is "yes, the proprietary firmware has been replacd by u-boot":

https://marc.info/?l=openbsd-tech=150417320727503=2
https://marc.info/?l=openbsd-tech=150416800125742=2
https://marc.info/?l=openbsd-misc=150324117732158=2

Still can't tell whether you need a 3.3v serial console adapter to install on 
the Pinebook. (it has a built in display!)




Re: Raspberry Pi support in 6.4

2019-01-17 Thread Frank Beuth

(misc got dropped?)

On Thu, Jan 17, 2019 at 04:28:05PM +, Stuart Henderson wrote:

I'll take a look at that. Why would you prefer the PINE64 over the RBP?


Partly due to the improved storage/connectivity options (especially on
rockpro64) but largely because there seems a bit more developer interest
in them than in the rpi.


Is it binary-blob-free?

The Pinebook looks great, and a quick glance at the archives raises hopes that 
the answer is "yes, the proprietary firmware has been replacd by u-boot":

https://marc.info/?l=openbsd-tech=150417320727503=2
https://marc.info/?l=openbsd-tech=150416800125742=2
https://marc.info/?l=openbsd-misc=150324117732158=2

Still can't tell whether you need a 3.3v serial console adapter to install on 
the Pinebook. (it has a built in display!)




Raspberry Pi support in 6.4

2019-01-17 Thread Frank Beuth

(resending as 1st message didn't go through?)


Has OpenBSD's support for Raspberry Pi devices improved much with 6.4? All the
documentation I can find online regarding this platform and OpenBSD refers to
6.3, and suggest that the Raspberry Pi support is very limited (no packages?).

The changelog for 6.4 notes for example:
"Implemented an EFI driver to allow PXE boot over EFIs Simple Network
Protocol, allowing TFTP boot on U-Boot based armv7 and arm64 machines."

Does this allow installing without a serial console?

These posts seems to suggest booting from the microSD card (vs needing external
USB drive) may be possible, but it's not very clear:
http://openbsd-archive.7691.n7.nabble.com/OpenBSD-current-doesn-t-boot-on-Raspberry-Pi-3-Model-B-td352103.html
http://openbsd-archive.7691.n7.nabble.com/OpenBSD-on-Raspberry-pi-3-model-B-td332780.html#a343278



Re: Automated remote install

2018-12-21 Thread Frank Beuth

On Wed, Dec 19, 2018 at 07:24:12AM -0800, andrew fabbro wrote:

Virtually all of the better KVM hosts offer an OpenBSD ISO, and in my
experience, 100% will add it to their library if you request it.


I did a quick survey, and found that of the providers I currently work with who 
offer OpenBSD ISOs, most/all of them:


- Require using VNC during installation (no automated install)
- Do not offer encrypted VNC

... "Now I remember why I started this thread!"

While setting up SSH key-based auth as part of the install process will 
mitigate someone sniffing passwords and using them to log in, if you have any 
suggestions for securing this kind of setup further, they would be welcome.


(No, switching to Vultr/Linode/etc is not an option)



Re: Automated remote install

2018-12-20 Thread Frank Beuth

On Wed, Dec 19, 2018 at 07:24:12AM -0800, andrew fabbro wrote:

Virtually all of the better KVM hosts offer an OpenBSD ISO, and in my
experience, 100% will add it to their library if you request it.


That's an excellent idea, especially from the perspective of making OpenBSD 
adoption easier for others as well. ("click the button" vs "don't forget the 
`--hail-puffy-full-of-grace` flag on `ansible-playbook`")


In this particular case -- where I frequently need to spin up servers in exotic 
and unusual places -- it's not ideal, of course.