Re: New laptop recommendations

[bytevolcano]

In his defense, you did exactly that which you are accusing him of, not
providing "technical" arguments. "Oh look at this laptop which I've
apparently never used but I'd recommend you look into anyway."

"I hear they're quite nice, and are running coreboot straight from the
factory." It sounds like pandering to ideology without technical merit.


As for my recommendation, I've had some decent success with Panasonic
Toughbooks (CF-30 and CF-31 so far). I'll see if I can bring up a dmesg
when I get a chance. They are physically sound units too.

Most stuff seems to work with 6.3 + syspatches on the CF-31 but I can't
work out how to disable the gestures (I don't seem to have a
"mouse.tp.tapping" variable when using wsconsctl(8)).


On Tue, 19 Jun 2018 13:19:55 -0700
Jordan Geoghegan  wrote:

> On 06/19/18 11:20, li...@wrant.com wrote:
> > Tue, 19 Jun 2018 09:59:45 -0700 Jordan Geoghegan   
> >> Have you considered one of the Librem laptops by Purism? I hear they're
> >> quite nice, and are running coreboot straight from the factory.  
> > The pinnacle of bullshit talk, utter nonsense, no technical value at all.
> >
> >  
> You don't have to be a snarky prick about things-- I don't hear you 
> making any suggestions or providing any "technical" arguments or giving 
> reasons for how/why my suggestion is "utter nonsense".
> You want a dmesg? You want the stats on the laptop? I'm not your 
> secretary, you know how to Google. Don't be aggressive just for the sake 
> of being aggressive.
> 
> Cheers,
> Jordan
> 

Re: bug tracking system for OpenBSD

[bytevolcano]

If I were to set such a thing up, I wouldn't even bother pulling stuff
from tech@ and bugs@ at all. Too much work, no real benefit. I would
simply have the bug tracker to all new bugs, and maybe keep the bugs@
list open concurrently with the tracker for a period to allow older bugs
to be resolved.

Before all that, I would ask if OpenBSD really needs a bug tracker.
The project seems to do well even without one, and maybe the devs are
satisfied with bugs@ and tech@ already. What issues/problems in
workflow will a bug tracker resolve that cannot be covered by bugs@ and
tech@ lists?

On Mon, 25 Dec 2017 14:46:25 -0800
Kai Wetlesen  wrote:

> Agreed, partially, with both of you. It may be possible to automatically 
> filter 
> some of the chaff (user errors and support requests in disguise) 
> in one large batch so to pressed the DB but forwarding mailing list touches 
> to the bug tracker would make things ugly fast.
> 
> What would be involved to pull the current state of bugs@ and tech@?

Re: Integrating "safe" languages into OpenBSD?

[bytevolcano]

On Mon, 4 Dec 2017 16:24:52 +0100
Nicolas Schmidt  wrote:

> So they wrote a program that was a) shitty and b) memory-safe? Those are two 
> orthogonal dimensions. Also, the anecdotal evidence that safe languages 
> attract bad programmers does not imply that using safe languages is bad: a 
> good programmer won't suddenly commit such atrocities as you mentioned, just 
> because they use a safe language.

A good programmer won't even need these languages in the first
place. Case in point, the entire OpenBSD dev team. :)

> Finally, your example probably speaks more about business practices than 
> about safe programming languages. If you want to compare Java to a 
> non-memory-safe language, you should compare it to one that is also designed 
> *for* (instead of *by*) programmers, like Cobol.

It goes back to the point I make though, that these languages encourage
this kind of behavior by promoting a false sense of security, hence complacency.

Re: Chip cheaper than chips

[bytevolcano]

Better yet, get rid of such insane rubbish in the first place. Why
would you want a remote admin tool built into the CPU out of all
things?

On Mon, 4 Dec 2017 13:46:02 +
Kevin Chadwick  wrote:

> Dangerous Bugs aren't new such as with core2duo but this is looking
> insane. The Apollo Lake chips are really impressive, just a shame they
> are intrinsically covered in #*&%. Hopefully public pressure might
> cause Intel to release firmware with a proper safe mode switch.

Re: Integrating "safe" languages into OpenBSD?

[bytevolcano]

I've always subscribed to the idea that too much safety results in too
may idiots, and the same is true for all these "safe" programming
languages. "Oh I don't have to write any form of bounds-checking,
because the language will do it for me."

To add further insult to injury, if the language's bounds checking kicks
in first your program may do something worse than just corrupting its
own memory. In my experience, apps written in these "safe" languages
(usually web apps or bloatware) actually have been the most bug-ridden
and bloated.

On Sun, 3 Dec 2017 15:54:43 -0500
Daniel Wilkins  wrote:

> And on top of what Theo said: rewriting stuff in "safe" languages doesn't 
> reduce
> the need for mitigations *anyway*. Nobody's rewriting all of the ports tree in
> memory safe languages.
> 

Re: Chip cheaper than chips

[bytevolcano]

Not yet thanks. Not if it has that flawed Intel ME in it, I don't want
it running on my routers. I have enough trouble coming to grips with
AMD's Platform Security Processor rubbish, but at least that hasn't got
any known exploits, and the firmware blob for it appears much smaller.

On Fri, 01 Dec 2017 14:48:59 -0500
Rupert Gallagher  wrote:

> I am drooling for an Intel Atom C3308. Two cores, but who cares? Higher 
> context switch: so what? It is faster than quad-core pcengines! It supports 
> m.2, to finally replace mPCI and mSATA with a single universal connector. It 
> has both aes-ng and qat, to make vpn faster than fast! It costs 32$!!! Give 
> it to me! GIVE IT TO MEEE!!!
> 
> Can we setup an *hail mary* to pcengines and ask them to upgrade?
> 
> http://ark.intel.com/products/97935?ui=BIG

Re: The "like" factor

[bytevolcano]

On Mon, 20 Nov 2017 00:40:38 +0100
 wrote:

> bytevolc...@safe-mail.net wrote:
> > Perhaps it isn't just word/excel, but rather, getting used to the
> > operating system changes and its antics. It appears you have changed
> > their OS and their software, and this has upset them. No training
> > was provided explaining to them the nooks and crannies of the new
> > software, so they are frustrated as they are forced to satisfy
> > someone elses' nerdgasm.  
> 
> How is office politics necessarily equivalent to a 'nerdgasm'?

Think about this. You change the toolset they've been used to for
years, with something radically different. Whether or not you like it,
OpenOffice/Libreoffice/OpenBSD/Linux is radically different from a MS
Office/Windows setup. Now instead of coming to work and just doing the
job they were assigned to, they now have to learn new bits of software,
and you "don't understand the problem."

> Either way, aren't most 'desktop environments', and libreoffice,
> 'sold' on the premise that it's so easy to convert from M$ poop?


> Given the situation he described it was more like windoze nt 5.2. I
> could be wrong on that, though.

Doesn't matter. It appears he just forced his users to use radically
different software to do the same task, without understanding what they
face, or justifying his reason for the change to the users.

> Yeah, but like in most other abusive relationships, those people find
> it very hard to leave M$, whatever they do.
> 
> And will still eye a potential replacement partner with a lot of
> scepticism (not quite unjustified).

It won't help the case if you come across as unsympathetic/unwilling to
understand your users, and it won't help if you don't try to work with
them to resolve the issues.

This is the key to solving the "like" factor, as Rupert calls it. The
users rightfully want a justification for the change, and they won't
understand "oh this software is open source, so we're not locked in to
proprietary closed Microsoft software." They won't care either, they
just want to do the job and go home.

I don't do this kind of thing anymore, but whenever I had to change the
system around, some retraining was in order and I would provide the
user with a comparison on how they did something in the old system vs
how they do it in the new system.

Re: SPOOFED: Re: The "like" factor

[bytevolcano]

Perhaps it isn't just word/excel, but rather, getting used to the
operating system changes and its antics. It appears you have changed
their OS and their software, and this has upset them. No training was
provided explaining to them the nooks and crannies of the new software,
so they are frustrated as they are forced to satisfy someone elses'
nerdgasm.

I notice a big difference between modern MS Office and
LibreOffice/OpenOffice, which is why I prefer the latter. I also notice
a big difference between OpenBSD and Windows 10, and you would have to
be a blithering idiot to not notice the differences.

You seem to have forgotten the huge uproar Microsoft created in
2006/2007 with the idiotic "ribbon" interface. This is similar, but on
a much smaller, more local scale.

On Sun, 19 Nov 2017 17:44:06 -0500
Rupert Gallagher  wrote:

> We nerds are the other side of the problem, because we are apparently
> unable to understand their problem. We have little simpathy for those
> who frown without evidence of an actual problem. Perhaps this is an
> example that humans still find it comfortable to "follow and go along
> together", like a herd of sheeps. Since "word" and "excel" is what
> they hear and use, perhaps they feel "cheap" or "non-standard" by
> using something else. Perhaps all we need to do with libreoffice is
> to improve its spash-screen, its icons and menus, and they will never
> notice the difference.
> 
> Sent from ProtonMail Mobile

Re: DMCA Free OpenBSD VPS Hosting, multiple payment methods

[bytevolcano]

I want to see a certain individual who can actually string a coherent
sentence of proper English rather than typing like a texting stoner
because they are too lazy to understand how a keyboard works. It would
be even better if that individual actually understood what they post.

On Fri, 20 Oct 2017 06:28:52 +
flipchan  wrote:

> I want to c a system that Auto encrypts it vms (can "easily" be done
> with some lines of python/whateverulike) and just forward all abuses
> to the customer, some isp's does this , however they are fucking
> assholes ISP that are retarded like dg-access in sweden who doesn't
> care about its customers , I am thinking that Switzerland would be a
> good way to host something in but as allways do allooot of research,
> try out acouple of different and c who works

Re: code duplication

[bytevolcano]

Just a tip from an outsider.

I would suggest you show a little sympathy for those who are getting
spammed by useless Nigerian scammers, cryptovirus authors, and the
like, claiming to be some kind of "Head of Financial Business
Management Department Business Managing Director" or some other sort of
made up title.

It would do you a lot better than whinging over a generic piece of text
that wasn't directed specifically towards you anyway, and then calling
people names, then whinging when your behaviour gets called out.

If I received the same piece of text, the first thought would be that
at least the OpenBSD mailing list maintainer thinks the same way as I
do about spammers. I even had a recent spammer impersonate Theo de
Raadt!

This is why the OLPC rubbish that went on about a decade ago did not
sit well with me.

On Sat, 26 Aug 2017 17:53:27 +0200
 wrote:

> Hi,
> 
> dera...@openbsd.org wrote:
> > Then please demonstrate your sensitivity by stopping use of the
> > OpenBSD project's mailing lists.  
> 
> Oh? Who's the thin-skinned one, now?
> 
> > Obviously what I'm saying isn't a personal insult.  
> 
> I didn't even know his name, still don't know his e-mail addr, and
> certainly didn't send a message to postmaster yelling at him that he's
> a jerkass. I just referred, in passing, to his mail swerver's
> behavior.
> 
> That is all. 
> 
> > I just came
> > to the conclusion you are a loudmouthed jackass.  
> 
> Okay, if I infer what you mean correctly: no, I did not mean that Todd
> is necessarily a complete jerkass, just 'cause he (indirectly) behaves
> to me that way, just once.
> 
> I thought that was clear. Since it obviously is not, I apologize.
> 
> > So go away.  
> 
> *shrugs* I suppose I can forget about you taking a look at my problems
> with the wdc_pcmcia code, then.
> 
> --schaafuit.
> 

Re: Can I use OpenBSD as a desktop system?

[bytevolcano]

On Sun, 11 Jun 2017 02:32:10 +0300
li...@wrant.com wrote:
...
> Hi Nicolas,
> 
> Soul of root canal is a half retarded troll, totally lacking any
> character. I can not believe you're still falling for their simply
> elemental tactics..
> 
> There is one absolutely zero diff between my init reply and Nick
> Holland's. Continued further this thread is funny, amusing, and a
> complete time waste.
> 
> For the time being I can say you're all right and correct, but about
> amiss. It is not any question "can they", it is those questions why
> "won't they"..
> 
> OpenBSD has always been and will continue to be, most developer use
> system. Many if not most of us use the system on all machines
> completely dedicated.
> 
> You, Nicolas, can not defend any troll position here.  They can not
> use it.
> 
> Kind regards,
> Anton Lazarov
> 

With a name like SOUL_OF_ROOT_CANAL I wonder what he is trying to
achieve. He's not likely to hurt anyone, but he'll get a lot of
mischievous or sarcastic responses.

As for using OpenBSD as a desktop system: yes it is possible with a bit
of work. Over the years I have created a decent configuration of a basic
desktop using the FVWM in the base. The good thing is that once you
have done the hard work, it seems to survive major updates if you back
up the right config files, sure beats Windows and the registry.

As newer versions of OpenBSD are released, I may tweak the setup if the
new release comes with an interesting feature, or removes a feature, or
allows my configuration to be simpler.

I hope to put Windows to rest by 2020, just as Windows 7 reaches the
end of extended support.

Re: Sad story

[bytevolcano]

Then the backup was restored, and they all lived happily ever after. :)

On Mon, 5 Jun 2017 12:14:51 +0200
"L. R. S."  wrote:

> Forgot the passphrase of a full-disk encrypted OpenBSD system ;_;
> So many documents will be lost, like [coughs] accesses to NULL.
> 
> 
> --luiz r.
> 

Re: Qubes-OS is "fake" security

[bytevolcano]

Virtualization has its uses though, despite the hype. It is good for
testing different system configurations before deployment, and is also
a good way to save on physical resources for configuring multiple
low-usage services that may require different OS or system config, such
that it is not possible to host these services on the same OS.

Whilst there may be some security benefits to whatever isolation is
provided by virtual machines, the real advantage here is the savings on
physical resources.

On Sat, 13 May 2017 00:12:35 +0300
valerij zaporogeci  wrote:

> "just a bunch of masturbating monkeys."
> this is the best definition of Hardware Virtualization hype.
> 
> 2017-05-12 22:20 GMT+03:00, Daniel Ouellet :
> > May I suggest you go read the FAQ before you spread misinformation.
> > Qubes doesn't use KVM, it's built on Xen, and calling it just a GUI
> > is like calling OpenBSD just a bunch of masturbating monkeys.
> >  
> >> On May 12, 2017, at 2:37 PM, flipchan  wrote:
> >>
> >> Qubes os is just linux with a gui for some kvm vms(it sux)
> >>  
> >>> On May 12, 2017 5:57:11 PM GMT+02:00, I love OpenBSD
> >>>  wrote:
> >>>
> >>> Both OpenBSD and Qubes OS don't guarantee
> >>> perfect security.
> >>> Qubes OS has a different take on security
> >>> than OpenBSD. Both have different
> >>> advantages and disadvantages.
> >>> Physical separation is more expensive
> >>> and you need to transport more devices
> >>> from place to place.
> >>> Qubes OS lets you run mainstream OSes.
> >>> OpenBSD is a OS and is a great tool to
> >>> get to know Unix-like OSes. It is also
> >>> a great environment to practise programming
> >>> in C language. See "Developing Software
> >>> in a Hostile Environment". There is a
> >>> "The J for junk option", pledge(2).  
> >>
> >> --
> >> Take Care Sincerely flipchan layerprox dev  
> >
> >  
> 

Re: pledge for sockets

[bytevolcano]

On Sun, 30 Apr 2017 00:29:01 +1000
 wrote:
...
> Even with "block reset all" in PF rules, nc does this.
> 
> It would be nice if the "reset" keyword tells the kernel to return
> EACCES when bind(2) is called on a port blocked by PF rules for a
> particular user.
Mistake pointed out to me off-list.

s/reset/return/

I did have "return" in the ruleset, not "reset".
Loaded no problem, and same result. I just typed it while fatigued.

Re: pledge for sockets

[bytevolcano]

I can imagine pledge(2) becoming very complex if individual ports are
blocked. It is not just the syscall, it's also the code in the
kernel. From what I can gather, pledge is really to restrict processes
to a subset of functions available, rather than restricting each
individual argument, unless there are exceptional reasons for doing so.

However, out of curiosity I've been tinkering with PF rules.

Ruleset:

block drop all
pass in proto tcp from any to any port 65535 user test2

Then running as user "test" (NOT test2):

$ nc -l 65535

Note nc stays there, probably opened the socket successfully.

Even with "block reset all" in PF rules, nc does this.

It would be nice if the "reset" keyword tells the kernel to return
EACCES when bind(2) is called on a port blocked by PF rules for a
particular user.

Such a facility would even be better than "privileged ports" as many
applications which listen on these ports cannot even be blocked
reliably with PF rules, as per pf.conf(5):

The user and group arguments refer to the effective (as
opposed to the real) IDs, in case the socket is created by
a setuid/setgid process.  User and group IDs are stored
when a socket is created; when a process creates a
listening socket as root (for instance, by binding to a
privileged port) and subsequently changes to another user
ID (to drop privileges), the credentials will remain root.

On Wed, 26 Apr 2017 11:19:20 +
Luke Small  wrote:

> I'm not saying to alter pledge necessarily, maybe make new system call
> like pledge. There aren't any per-process pf rules that are applied.
> When a socket connects to a remote or local server and pf makes a
> state, it has the originating randomized port. Pf rules can be made
> that target those randomized port numbers, but maybe there could be a
> more elegant way like intervening in connect() and bind() calls.
> 
> >you can have rules to filter by user >for both
> >incoming and outgoing connections, see
> >http://man=2Eopenbsd=2Eorg/OpenBSD->6=2E1/pf=2Econf=2E5#user  
> 
> >I don't think there's too much gain in >adding
> >support for this kinda thing in pledge >but
> >that's for the devs to decide=2E=20  

Re: Is randomizing UID/GUID would make sense?

[bytevolcano]

Thanks for the start points, Christian and Philip.
I would have never thought about those use cases.
I'll definitely look into this further.

On Wed, 19 Apr 2017 13:31:08 + (UTC)
Christian Weisgerber  wrote:

> On 2017-04-19, Philip Guenther  wrote:
> 
> > For a broader answer to the "why?", take a look at the patches under
> > /usr/ports/ which add uses of the *_deterministic() calls.  
> 
> For instance, take graphics/netpbm and look at its multitude of
> image manipulation tools that take a -randomseed=integer argument
> to ensure that the same result can be obtained on separate
> invocations.
> 

Re: Is randomizing UID/GUID would make sense?

[bytevolcano]

An idiot whose question lacks clarity. My apologies.

Of course software uses it. What I was trying to ask was *why* would software
actually nee a deterministic PRNG, rather than "what software uses it."
In other words, what will break if the PRNG was non-deterministic?

Yes, it may be "standards mandated" in some cases (r1.39, bin/ksh/var.c) or
used by 60 pieces of software, but why would software require a PRNG to be
deterministic?

That is my question, not "what apps and standards need it?" but "what usage
cases require it, and can this be replaced with a deterministic PRNG?"

On Mon, 17 Apr 2017 23:30:04 -0600
"Theo de Raadt"  wrote:

> It's really unfortunate that we aren't running an open source project
> and making available all the source for the tool called grep.
> 
> So that it can be studied, rather than questioned by an idiot
> uninterested in the exercise of selflearning.
> 
> Maybe those source files even have commit logs - even better PUBLIC
> COMMIT LOGS - which might explain the rationale!  No, that's unlikely.
> 
> So let's just yak about it, right?
> 
> Rest of your email deleted because what's the point

Re: Is randomizing UID/GUID would make sense?

[bytevolcano]

On Sun, 16 Apr 2017 12:01:48 + (UTC)
Stuart Henderson  wrote:

> On 2017-04-15, 
>  wrote:
> > OpenBSD still randomizes PIDs, but I don't see the point these days:
> > https://security.stackexchange.com/questions/88692/do-randomized-pids-bring-more-security/89961
> >   
> 
>   'Protect against PID prediction vulnerabilities affecting mostly
>software which use the PID value to generate temporary file names.
>This was a common concern at that time, but today I think it would
>be quite rare to encounter production-level software still not
>using a proper method.'
> 
> Between some of the less common software that is still used, and
> various sysadmin shell scripts people might have around, I don't
> think it's all that unlikely.
> 
>   'A PID is not designed to seed a random number generator or generate
>session ID or cookies.'
> 
> Correct that it's not designed for that. But we looked into this a lot
> when introducing srand_determinstic(3).

Are there any applications out there that explicitly require the PRNG
to be deterministic? It doesn't make sense to have that kind of thing
there for minute corner cases, such as if someone decides it's a
brilliant idea to use the contents of a deterministic PRNG as a hash.

> It's still *very* common to
> seed based on pid, time, or a combination of the two, either as the
> main method, or as a fallback if /dev/urandom can't be opened (as may
> happen as a result of FD exhaustion [possibly attacker-triggered] or
> in a chroot jail).
> 
> t = (unsigned char)getpid();
> while (i < size) {
> do {
> buf[i] = ((unsigned char)rand()) ^ t;
> } while (buf[i] == 0);
> t = buf[i++] << 1;
> 
> The srand_deterministic change makes this less of a problem on OpenBSD
> for programs using rand(), but sometimes programs have their own PRNG
> and aren't seeding it nicely, any extra protection we can give these
> seems useful.

Surely looking up a pointer to some have O(n) or O(log n) worst case,
since it has to traverse the list? Quite close for a list full of
random PIDs.

Surely this creates a bit more complacency, "Oh the OS generates random
PIDs anyway, let's use that to seed our RNG." Hopefully such practices
is abolished in favour of more robust methods.

Not suggesting the random PIDs are a bad thing, but I am curious as to
how much extra code and cost is needed to implement this over a
"sequential" PID that's just an index to an array.

> 
>   'As a general preventive measure, "If something can be random, make
> it random."'
> 
> With OpenBSD's random subsystem it is intentional to have many
> consumers. See http://www.openbsd.org/papers/hackfest2014-arc4random/.
> The idea is to slice up the chacha20 (formerly arc4) stream as much
> as possible.
> 

I do like the way this is implemented, and it is well integrated within
the system too.

Shame the function was called arc4random() and not sorandom() or
something. Little too late to change it now though I guess.

Re: Is randomizing UID/GUID would make sense?

[bytevolcano]

On Sat, 15 Apr 2017 23:16:18 -0600
"Theo de Raadt"  wrote:

> > Responding to multiple messages:
> > 
> > On Fri, 20 Jan 2017 08:43:46 +0100
> > "minek van"  wrote:  
> > > I can see that the default users and when creating new ones have
> > > their UID/GUID incremented by 1. 
> > > 
> > > Could it bring more security if the UIDs/GUIDs would be random?  
> > 
> > On Mon, 23 Jan 2017 11:51:29 -0500
> > andrew fabbro  wrote:  
> > > The OP was just talking about changing from "last +1" to
> > > arc4random. Synchronizing UID/GID across servers (if you're not
> > > using a directory of some sort) is the same headache regardless
> > > of how you pick them.
> > > 
> > > If the OP meant every server has different, unique randomized
> > > UID/GIDs then that's a separate craziness.  
> > 
> > I can see this randomisation making systems management a bit more
> > difficult as a non-random GUID/UID setup can be used to do things
> > like:
> > 
> > GID 0 = wheel
> > GID 1-999 = privsep users, daemons, system
> > GID 1000-32765 = ordinary logins
> > GID 32766 = nogroup
> > GID 32767 = nobody
> > 
> > Because the separation is clear and not so random, you can also set
> > up GIDs/UIDs (1000-32765) permanently across a site where they need
> > to be static, in the case of logged-in users. Very necessary for
> > backups.
> > 
> > However, the users 1-999 may change depending on what order you
> > install packages in.
> > 
> > OpenBSD still randomizes PIDs, but I don't see the point these days:
> > https://security.stackexchange.com/questions/88692/do-randomized-pids-bring-more-security/89961
> >   
> 
> 
> Sorry you lost me.
> 
> I can't tell if you are supporting a useless idea, or declaring that a
> useless idea is not worth supporting.
> 

The latter. In this case I don't think UIDs/GIDs benefit from being
random for the above reasons.

Re: Is randomizing UID/GUID would make sense?

[bytevolcano]

Responding to multiple messages:

On Fri, 20 Jan 2017 08:43:46 +0100
"minek van"  wrote:
> I can see that the default users and when creating new ones have
> their UID/GUID incremented by 1. 
> 
> Could it bring more security if the UIDs/GUIDs would be random?

On Mon, 23 Jan 2017 11:51:29 -0500
andrew fabbro  wrote:
> The OP was just talking about changing from "last +1" to arc4random.
> Synchronizing UID/GID across servers (if you're not using a directory
> of some sort) is the same headache regardless of how you pick them.
> 
> If the OP meant every server has different, unique randomized
> UID/GIDs then that's a separate craziness.

I can see this randomisation making systems management a bit more
difficult as a non-random GUID/UID setup can be used to do things like:

GID 0 = wheel
GID 1-999 = privsep users, daemons, system
GID 1000-32765 = ordinary logins
GID 32766 = nogroup
GID 32767 = nobody

Because the separation is clear and not so random, you can also set up
GIDs/UIDs (1000-32765) permanently across a site where they need to be
static, in the case of logged-in users. Very necessary for backups.

However, the users 1-999 may change depending on what order you install
packages in.

OpenBSD still randomizes PIDs, but I don't see the point these days:
https://security.stackexchange.com/questions/88692/do-randomized-pids-bring-more-security/89961

Re: Substitute for other variables in pkg.conf(5)

[bytevolcano]

On Fri, 7 Apr 2017 17:44:30 + (UTC)
Stuart Henderson  wrote:

> On 2017-04-06, 
>  wrote:
> > Since pkg.conf(5) is no longer used, how would you set fullwidth,
> > loglevel, nochecksum, ntogo?
> >
> > In particular, I am interested in fullwidth, loglevel, and ntogo.
> >
> >  
> 
> ntogo is now on "pkg_add -V".
> 
> nochecksum (to stop verifying checksums during pkg_delete) is on by
> default, use "pkg_add -D checksum" to enable verifying these again.
> 
> I think the others have gone.
> 

Thanks Stuart. I will see what I can do about loglevel and fullwidth.
The fullwidth is not a major issue (would be nice though), and I am
guessing loglevel > 1 was never implemented?

Re: Topics for revised PF and networking tutorial

[bytevolcano]

On Mon, 10 Apr 2017 17:10:55 -0500
Adam Thompson  wrote:

> You've asked almost the same question as "why does anyone need 
> tutorials? just read the man pages!" just at the next level up.  The 
> answer is because the man pages aren't adequate to cover every
> scenario, and not everyone can read man pages effectively.  People
> have different learning styles, if nothing else.  I learn best by
> seeing examples and asking questions.  (In fact, the lack of good
> examples is a pet peeve of mine with the OpenBSD man pages, but
> that's another story.)

Another issue with the man pages is that there is extremely limited
indexing. I have often had to google or find tutorials, only to find
there's this "new" device or program I never heard of.

$ apropos -i EXDEV
apropos: nothing appropriate
$ man errno | grep -i EXDEV
 18 EXDEV Cross-device link. A hard link to a file on another file system
$

Either I am doing something wrong here, or the indexing is junk.

> 
> I've attended Peter's seminar two?, maybe three? times now, and got 
> something new out of it each time - some nuance that wasn't obvious
> just from reading pf.conf(5).  Sometimes it was something Peter said, 
> sometimes it was something another attendee said.  That's the value
> of attending any training class or seminar, not just this one for PF.
> 
> The tutorial is aimed not at people who would go and produce another 
> tutorial, but at ordinary system administrators who don't have time
> to pore over the entire manpage, who want the most relevant
> information to them distilled and delivered efficiently.
> 
> Plus, this year it appears that Peter is co-delivering the seminar
> with Massimiliano Stucchi from RIPE, so it will presumably cover a
> lot of IPv6 topics as well, which are poorly represented in existing
> materials and yet increasingly relevant.

And for those of us who cannot attend, hopefully it will be on video.

> 
> Disclaimer: I now help organize (one small) part of BSDCan & PgCon,
> so I'm not *entirely* unbiased, but this is pretty much what I would
> have said the first two years I attended, anyway.
> 
> -Adam

Re: Topics for revised PF and networking tutorial

[bytevolcano]

On Fri, 7 Apr 2017 17:39:16 + (UTC)
Stuart Henderson  wrote:

> On 2017-04-06, 
>  wrote:
> > On Wed, 5 Apr 2017 22:44:54 + (UTC)
> > Stuart Henderson  wrote:
> >  
> >> On 2017-04-05, 
> >>  wrote:  
> >> > I've been using a trick to emulate scheduled rules using IP
> >> > tables.
> >> 
> >> Nice trick. Anchors are also good for this.
> >> 
> >> But don't forget that active connections won't be dropped unless
> >> you also flush the relevant states.
> >>   
> >
> > Anchors do not work with securelevel=2. This trick works in
> > securelevel=2.  
> 
> Oh, people actually use that? :)

Oh I reckon someone out there runs tetris(6) on their firewall.
I use it when I am confident the ruleset is stable. Of course, I have
to restart the gateway everytime I change the rules.

> 
> > As for active connections, the goal here is to prevent new
> > connections being made after closing time. I don't want my
> > connection to close just because it is a few seconds after closing
> > time, especially when I already got in before the ports were
> > closed. It may be worth closing long-standing connections
> > eventually though.
> >
> > Maybe something like this:
> >
> > 0 18 * * * *root/sbin/pfctl -F states
> >
> >  
> 
> If it's given as an example for something, it's definitely important
> to point out about active connections. -F states will kill the
> "wanted" states too, I use pfctl -k to knock out just the relevant
> hosts.
> 

I was wondering about that. I missed -k while scrolling through the man
page. Labeling the rules may also be helpful:


# Schedule Table
table  persist

# Scheduled access to HTTP
pass in on egress proto tcp from  to any port http rdr-to $web_server 
keep state label sched_ip

# Scheduled access to SSH
pass in on egress proto tcp from  to any port ssh keep-state label 
sched_ip


System crontab:

0 18 * * *  root/sbin/pfctl -k label -k sched_ip

Substitute for other variables in pkg.conf(5)

[bytevolcano]

Since pkg.conf(5) is no longer used, how would you set fullwidth,
loglevel, nochecksum, ntogo?

In particular, I am interested in fullwidth, loglevel, and ntogo.

Re: Topics for revised PF and networking tutorial

[bytevolcano]

On Wed, 5 Apr 2017 22:44:54 + (UTC)
Stuart Henderson  wrote:

> On 2017-04-05, 
>  wrote:
> > I've been using a trick to emulate scheduled rules using IP
> > tables.  
> 
> Nice trick. Anchors are also good for this.
> 
> But don't forget that active connections won't be dropped unless you
> also flush the relevant states.
> 

Anchors do not work with securelevel=2. This trick works in
securelevel=2.

As for active connections, the goal here is to prevent new connections
being made after closing time. I don't want my connection to close just
because it is a few seconds after closing time, especially when I
already got in before the ports were closed. It may be worth closing
long-standing connections eventually though.

Maybe something like this:

0 18 * * * *root/sbin/pfctl -F states

Re: Topics for revised PF and networking tutorial

[bytevolcano]

I've been using a trick to emulate scheduled rules using IP tables.
It would be nice to have something like this covered.
I have even seen it in the silliest of home router firewalls.


First, create a rule with a table like so:

# Schedule Table
table  persist

# Scheduled access to HTTP
pass in on egress proto tcp from  to any port http rdr-to $web_server 
keep state


Then add to crontab jobs like this:

# Top secret business server opens from 9AM-4PM during weekdays, and 2PM-4PM 
weekends. 
0 9 * * 1-5 root/sbin/pfctl -T add -t schedule_ip 0.0.0.0/0 # open (Mon 
- Fri)
0 14 * * 6-7root/sbin/pfctl -T add -t schedule_ip 0.0.0.0/0 # open (Sat 
+ Sun)
0 16 * * *  root/sbin/pfctl -T del -t schedule_ip 0.0.0.0/0 # close 
(everyday)

Very useful technique, and I also think this works under securelevel=2 (correct 
me if I am wrong, I haven't tried myself).
The 0.0.0.0/0 range is a very useful tool in many cases. 


On Sat, 1 Apr 2017 10:52:20 +0200
"Peter N. M. Hansteen"  wrote:

> Hi,
> 
> I thought I'd like to give you a heads up that there will be a "PF and
> networking" tutorial at BSDCan 2017 in Ottawa this June.
> 
> The session will however not be the Nth rerun of the old one, we're
> starting from scratch this time, and were looking for input on what to
> include.
> 
> Do you have questions on PF and related matters, or are there specific
> topics you would like to see covered?
> 
> We want to hear from you, either contact us directly at the reply-to
> address use the list.

Re: Why isn't OpenBSD in Google Summer of Code 2017?...

[bytevolcano]

This can all be done without GSoC, and OpenBSD is better off without it.
Obviously I cannot speak on behalf of any OpenBSD developers here, this
is just my thoughts based on observations of other open-source projects
that did GSoC over the years.

Some students were shit, letting the projects down and putting them at
risk of getting less slots allocated the next time. Some suffered
psychologically while trying to keep up with the GSoC requirements and
tight scheduling. Some were forced to rush things along the way and cut
out bits of work to submit their code by the due date.

When OpenBSD last participated in the GSoC, there were good projects
such as Capsicum, HAMMER2, Async. USB I/O, and some others. There were
no status updates or info. Again, I'm not sure what happened, but it
wouldn't surprise me if the OpenBSD project faced issues like the above.

On Wed, 05 Apr 2017 13:10:55 +
Luke Small  wrote:

> I imagine there are some projects that need some love that are on the
> back burner at the moment that could use some hacking; even if it is
> totally redone later by someone that wants to refactor it for privsep
> and such.

Re: OpenBSD httpd and HTTP/2

[bytevolcano]

On Fri, 31 Mar 2017 12:14:34 +0200
Reyk Floeter  wrote:

> Isn't QUIC the hot new thing now?  It is UDP, so Google can reinvent
> TCP and turn even more of their browser into an OS-replacement ;)

Oh come on now, how else will Google be able to claim they are
inventing or innovating? What will they say at the meetings with their
shareholders if they can't reinvent the wheel?

Perhaps Microsoft will join in and release IPv6 Service Pack 1.

> Seriously, there are benefits of implementing HTTP/2, and it would be
> an interesting exercise to do so, but it is also adds many problems
> and some complexity.

The benefits are there, but I feel it encourages lazy and disorganized
web development, leading to stupidly bloated and inefficient sites, and
requiring the latest stupidly bloated and inefficient browsers.

Back in the dial-up days, I remember web pages without much bloaty
rubbish. They had to be fast, because networks were high-latency,
low-bandwidth beasts.

More efficient protocols are great, but it's a bit like increasing CPU
speeds and RAM; fantastic, but not if the software starts becoming
bloated beyond your wildest dreams.

> 
> So: maybe.
> 
> Reyk

Re: Opinion about Rust and Go

[bytevolcano]

You know things are bad when a programming language is named after a
type of often-unwanted corrosion (often associated with iron alloys) or
a type of devastating plant fungus.

And what good are these "memory-safe" languages when there are so many
that you won't be able to remember them?

On Tue, 28 Mar 2017 20:12:48 -0400
Donald Allen  wrote:

> On 28 March 2017 at 17:59,   wrote:
> > Hello,
> >
> > I just want to know the opinion of OpenBSD developpers about Rust
> > and Go, I already know Ted's opinion.
> > http://www.tedunangst.com/flak/post/thoughts-on-replacement-languages
> >
> > As they are both touted as memory safe, what do you think about
> > them ?  
> 
> I've written some code in both and given up on both of them. I found
> Rust difficult to learn, mostly because the documentation is just
> awful, in my opinion. The principal writer, Klabnick, knows the
> subject matter, but he just doesn't write well, again, in my opinion.
> His first attempt at a Rust "Book" is currently being re-written. He
> now has a co-author. I've looked at the second attempt, filed some PRs
> to try to help, but finally threw up my hands when I was told that
> something that is standard practice in C *and* is supported by their
> software was not "idiomatic". They use that term a lot. It's a bit
> like a certain political party in the US that talks about freedom a
> lot. Then you find out that their definition of the word is "we want
> you to be free to do what we want you to do". It's too bad the
> documentation situation is at it is, because the language and its
> compiler have real potential.
> 
> Go is much better documented and, in general, feels more mature, more
> finished. But it just felt uninspired to me and I felt a sense of
> relief when I went back to C. C is far from perfect, but after all
> these years, we know its warts, the compilers are solid, it's
> extremely well documented (K, Harbison and Steele) and the libraries
> are . well, you all know.
> 
> When I don't need C's performance, I use Haskell, a brilliant language
> and the Glasgow compiler and libraries are excellent. Hackage provides
> a rich assortment of additional libraries.
> 
> >
> > Regards  

Re: doas(1) adjustable timeout length

[bytevolcano]

Understood (though in this case it looks unfinished when 99% of the
implementation is already present).

In any case you have answered my original question. Thanks, Ted.

On Tue, 14 Mar 2017 18:29:25 -0400
"Ted Unangst"  wrote:

> bytevolc...@safe-mail.net wrote:
> > I'm not saying "you must do everything my way or else", but rather I
> > am trying to understand the reasoning behind making this hardcoded
> > and fixed, as opposed to being admin-settable; maybe something is
> > planned here I am unaware of?  
> 
> We're trying to keep the options to a minimum, which keeps the
> implementation simple, but more importantly keeps the documentation
> short and reduces the number of decisions that need to be made.

Re: doas(1) adjustable timeout length

[bytevolcano]

>From what I have read, it appears to be 15 minutes on some systems and
30 minutes on others, and this can be adjusted by the admin without
having to recompile the code.

I'm not saying "you must do everything my way or else", but rather I
am trying to understand the reasoning behind making this hardcoded and
fixed, as opposed to being admin-settable; maybe something is planned
here I am unaware of?
Not saying we need all the bells and whistles of the sudo implementation
(eg. "sudo -v" adding 5 minutes to the timeout) but I can't see any
reason this shouldn't be admin-configurable.

I would like to work on a patch for this, but I want to ensure I don't
duplicate efforts if you have something planned which conflicts with my
patch. That's why I posted in misc@, because I don't have a patch yet.

On Mon, 13 Mar 2017 01:06:51 -0400
"Ted Unangst"  wrote:

> The timeout was originally 10 minutes, but changed to 5 after I
> discovered that was the sudo default. I think increasing to 10 is
> reasonable, since it seems likely other people also land in the 5-10
> minute window, and it's not dangerously long.

Re: doas(1) adjustable timeout length

[bytevolcano]

On one box I test configuration edits and backups, I find myself using
doas around once every 7-9 minutes, exceeding the 5 minute limit.
Another box is basically a gateway, so I don't exceed 2 minutes between
doas runs.

It would be nice to have the option of deviating from the default, and
the "persist" feature seems incomplete without the ability to adjust
the timeout from a fixed 5 minutes.
I didn't say anything until now, because I was under the
impression there was something else planned for the "persist" feature,
but there has I haven't seen anything about this in the mailing lists
since this: https://marc.info/?l=openbsd-tech=147314077009745

Since the first release with this feature will be 6.1, it seems logical
to make any syntax changes now rather than later. No kernel changes
needed here, since the timeout can be set with TIOCSETVERAUTH, so I
don't see any harm in giving admins the option of setting the timeout
with doas.conf instead of it being hard-coded into doas itself.

On Sun, 12 Mar 2017 10:20:46 -0600
"Theo de Raadt"  wrote:

> I'll ask the question: Why are you sure you need that?
> 
> > Are there plans (or perhaps code already being worked on) to allow
> > doas(1) 'persist' to have a different time other than 5 minutes? I
> > am thinking of writing a patch for this, but I do not want to
> > duplicate effort if the devs have other/similar plans ahead.
> > 
> > I would like to configure the timeout to be 1 minute on one of my
> > boxes, and 5-10 minutes on another box.
> > 
> > For instance, something like:
> > 
> > # 90-second persistence
> > permit persist=90 :wheel
> > permit nopass keepenv root
> > 
> > # 5-minute persistence
> > permit persist :captain
> > 
> > Or even:
> > 
> > # 90-seconds; timeout must be specified.
> > permit persist 90 :wheel  

Re: For the super paranoid

[bytevolcano]

>From your link:

AMD replied: "Thanks for the inquiry. Currently we do not have
plans to release source code but you make a good argument for
reasons to do so. We will evaluate and find a way to work with
security vendors and the community to everyone's benefit." The
product manager for AMD, AMD_james, continued in response to a
follow-up comment that claims AMD is "not considering it all
but only want to appease the potential buyers." AMD_james
replied: "Thanks for the feedback. Please believe me that this
has CEO level attention and AMD is investigating the steps and
resources necessary to support this. It is not the work of a
minute, so please bear with us as we define what we can do."

In other words: the fourth millennium will arrive first.

On Sun, 12 Mar 2017 12:47:06 +0100 (CET)
I love BSDs  wrote:

> >In order for me to trust AMD's implementation, they first need to can
> >that ridiculous Platform "Security" Processor. It is as useless and
> >dangerous as Intel Management Engine, running unknown code.
>
> Who know, maybe they are going to open source their firmware?
>
https://news.slashdot.org/story/17/03/10/2048236/message-for-amd-open-psp-wil
l-improve-security-hinder-intel
>
> Anyway I recommend "Wait and see".

doas(1) adjustable timeout length

[bytevolcano]

Hi,

Are there plans (or perhaps code already being worked on) to allow
doas(1) 'persist' to have a different time other than 5 minutes? I am
thinking of writing a patch for this, but I do not want to duplicate
effort if the devs have other/similar plans ahead.

I would like to configure the timeout to be 1 minute on one of my
boxes, and 5-10 minutes on another box.

For instance, something like:

# 90-second persistence
permit persist=90 :wheel
permit nopass keepenv root

# 5-minute persistence
permit persist :captain

Or even:

# 90-seconds; timeout must be specified.
permit persist 90 :wheel

Re: For the super paranoid

[bytevolcano]

In order for me to trust AMD's implementation, they first need to can
that ridiculous Platform "Security" Processor. It is as useless and
dangerous as Intel Management Engine, running unknown code.

A more plausible attack would be an application using malloc() for a
large segment of memory, and transmitting the "uninitialised" content,
which could contain private keys, sensitive documents, etc. from
applications that either don't zero the memory after finishing, or
programs which have crashed and the memory is now freely available
to other processes.

It would be nice in those cases to have different
keys for different pages, so that when a process is terminated, the
kernel can (instruct the CPU to) overwrite the key with a new random
number.

On Sat, 11 Mar 2017 20:18:37 + (UTC)
Christian Weisgerber  wrote:

> AMD thinks so.  Last year they announced support for memory encryption
> in future CPUs.  The top two Google hits:
> 
> http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v7-Public.pdf
> https://events.linuxfoundation.org/sites/events/files/slides/AMD%20x86%20Memory%20Encryption%20Technology%20LSS%20Slides.pdf

Re: Please: Is there ANY chance that Linux binaries might run again???

[bytevolcano]

On Wed, 8 Mar 2017 09:52:39 +1100 (AEDT)
Damian McGuckin  wrote:

> On Tue, 7 Mar 2017, Stefan Wollny wrote:
> 
> > Yes - I will (again) contact SoftMaker trying to persuade them to
> > provide an OpenBSD-version of their office suite. But they seem to
> > have none with some decent Unix/OpenBSD-knowledge, just Linux.
> > Sigh...  
> 
> I would buy SoftMaker on OpenBSD.

If SoftMaker only supplies binaries, they probably won't bother with
OpenBSD because with every release of OpenBSD, there has been a
compatibility break, and applications that work on OpenBSD 5.9 will not
work on OpenBSD 6.0.

OpenBSD is fine for open-source software where you can just recompile
the binaries for the new OpenBSD release, is no good for binary-only
software.

Re: https://undeadly.org

[bytevolcano]

I vaguely recall this sort of thing happening before with deadly.org;
this is how undeadly.org started.

Maybe undeadly.org will turn into [something with a zombie-like
name].org?

On Tue, 28 Feb 2017 10:59:24 + (UTC)
Stuart Henderson  wrote:

> On 2017-02-28, minek van  wrote:
> > fyi, undeadly.org has problems.  
> [snip]
> 
> After a mail like this, if I was hosting the site I would probably
> just pull the plug.

Re: Limits for bcrypt_pbkdf(3) vs bcrypt(3)

[bytevolcano]

cheers Ted,

On Tue, 07 Feb 2017 14:50:49 -0500
"Ted Unangst"  wrote:

> bytevolc...@safe-mail.net wrote:
> > 1. Does the 72-character limit also apply to bcrypt_pbkdf()
> > [presumably this will mean softraid(4) crypto won't accept
> > passwords >72 chars anymore]?  
> 
> No. There is no limit. (The inputs can also contain 0 bytes.)
> 
> > 2. What is the recommended buffer size to be passed to
> > bcrypt_pbkdf()?  
> 
> This is a strange question. It generates a key which you'd normally
> use to encrypt some data. So however much key material you need.
> 
> > 3. In the BUGS section in the bcrypt(3) man page it mentions that
> >crypt() returns a pointer to static data. Is it safe/smart to
> > assume this constraint also applies to bcrypt() calls?  
> 
> Yes. On OpenBSD, the preferred interface is actually crypt_newhash,
> which doesn't have this restriction.

Looking at the man page, I notice there is also no mention of
password length limit or recommended/minimum buffer size. Is this
implementation something like bcrypt_pkdf() in disguise?

Limits for bcrypt_pbkdf(3) vs bcrypt(3)

[bytevolcano]

I am investigating bcrypt_pbkdf(3) or bcrypt(3) to secure passphrases
within an existing application.

However, the man page for bcrypt_pbkdf() does not mention the
72-character password limit that bcrypt() does, especially given
bcrypt_pbkdf() appears to accept an output buffer whose length is the
caller's choice.

72 characters may seem short, but the application currently
concatenates a non-secret global file ID to the passphrase;
this can easily make the total length go past 72 characters. I am
interested in knowing if I will need to remove the concatenated info
from the input.

1. Does the 72-character limit also apply to bcrypt_pbkdf() [presumably
   this will mean softraid(4) crypto won't accept passwords >72 chars
   anymore]?

2. What is the recommended buffer size to be passed to bcrypt_pbkdf()?

3. In the BUGS section in the bcrypt(3) man page it mentions that
   crypt() returns a pointer to static data. Is it safe/smart to assume
   this constraint also applies to bcrypt() calls?

Some assistance clarifying this would be appreciated.
Thanks.

Re: How boot HDD-side crypto softraid from (bootable) USB disk? (AMD64/ARM. Currently installboot fails with "cross-device install"!..)

[bytevolcano]

Perhaps I should point out that the only reason I suggested installing
OpenBSD on the stick here was for recovery purposes, and for installing
the boot loader.

The boot loader allows you to select the HDD you have at the start. So
edit /etc/boot.conf *on the stick* as follows:

boot sr0a:/bsd

That should do the trick.

On your softraid volume is your plain, normal OpenBSD install (similar
to how it would be installed on a non-softraided partition). No trickery
needed there, and no need to store the "b" partition somewhere else
either, its fine on the softraid partition.

On Mon, 06 Feb 2017 05:17:22 +
Tinker  wrote:

> On 2017-02-06 11:40, bytevolc...@safe-mail.net wrote:
> > There is still an elephant in the room.
> > 
> > What if someone has physical access to your machine's USB ports, and
> > decides to boot something nasty from it, which in turn modifies the
> > firmware in your system (very likely to be possible due to stupid
> > "consumer-grade" junk like UEFI or OS-flashable BIOS without
> > hardware write protection).
> > 
> > This infected firmware can then scan through any keys that you
> > input, including the USB key disk, and the security of this
> > 'softraid "firewall"' is now compromised.  
> 
> Right, booting off USB provides no protection against physical
> attacks and nor against broken firmware.

Re: How boot HDD-side crypto softraid from (bootable) USB disk? (AMD64/ARM. Currently installboot fails with "cross-device install"!..)

[bytevolcano]

There is still an elephant in the room.

What if someone has physical access to your machine's USB ports, and
decides to boot something nasty from it, which in turn modifies the
firmware in your system (very likely to be possible due to stupid
"consumer-grade" junk like UEFI or OS-flashable BIOS without hardware
write protection).

This infected firmware can then scan through any keys that you input,
including the USB key disk, and the security of this 'softraid
"firewall"' is now compromised.

On Thu, 02 Feb 2017 10:43:34 +0800
Tinker  wrote:

> On 2017-02-02 10:27, Tinker wrote:
> ..
> > My motivation here for wanting the boot code on the USB stick, is
> > that I trust the USB stick more than my harddrive.  
> 
> Motivation:
> 
> What I meant to say here is that I like the notion of the harddrive
> as unsecure by definition, so that I only will trust its content
> through the "firewall" of the softraid crypto mechanism.
> 
> This is why I'm OK with storing softraid crypto data on the HDD but
> not the boot code.
> 
> The only thing, supposedly, that the HDD could do would be to give me 
> fake partition tables or partition data, and goofy partition data
> could only meaningfully amount to a replay attack, so those would be
> harmless in both cases.
> 
> So this would (supposedly) cut out the harddrive from the chain of 
> attack vectors, and that can be an important step in the direction of 
> security. Of course there is a plethora of security problems in
> addition to this one in any computer.

Re: -current

[bytevolcano]

On Fri, 25 Nov 2016 16:55:03 -0700
ch...@ccmach14.org wrote:

> Hello - Where can I get sys.tar.gz -current? Thanks! Chuck
> 

Greetings Chuck,

You can use the sys.tar.gz and src.tar.gz from the latest release (at
the moment 6.0) and use "cvs update -rHEAD" on it.

Re: Laptop Recommendations?

[bytevolcano]

On Sat, 12 Nov 2016 07:25:11 -0600
Chris Bennett  wrote:

> 
> I also notice that Thinkpads and Toughbooks seem to be the preferred
> choices for a cheaper laptop. I need a newer laptop too, so I will
> look into those on ebay.
> 
> Thanks
> Chris Bennett
> 

Toughbooks, when new, are definitely not cheap. Even when second-hand,
they are probably a little more expensive than their Thinkpad
counterparts. OpenBSD has a habit of working very well on older
ThinkPads.

Not that it's a bad thing though, you do get what you pay for. The
price difference is significant though, and boils down to the fact that
one brand is a solid, rugged machine built for field use, and how a
laptop should be anyway, and the other brand is a cheap Chinese
product, which relies upon shoddy and questionable quality control and
business practices.

For a second-hand Toughbook to be very cheap, it is usually almost a
decade old. However, a new Toughbook CF-31 will work around 90% well
with OpenBSD, though I am not sure about the optional GPS or HSPA modem.

Re: Laptop Recommendations?

[bytevolcano]

I seem to be doing fine on an old Panasonic Toughbook. They can be
bought quite cheap if you don't mind them being several years old.
Having said that, if you want a laptop that is "close to free", then
expect failures to be "close to free" also.

On Wed, 09 Nov 2016 23:47:52 -0600
Nathan Koch  wrote:

> Greetings Fair BSD Wizards,
> I am new to the lists. I am currently shopping for a new Xmas present
> for myself and am looking for a laptop that's portable and
> lightweight. Preferably fast, cheap (close to free),  light, and
> secure. If you have any recommendations before the stormy winter hits
> the prairies please let me know.
> 
> Thank you.
> Nate
> 
> 
> Sailing the South Saskatchewan. 

Re: What are the security features in OpenBSD 6.0 that are by default disabled?

[bytevolcano]

On Mon, 17 Oct 2016 14:38:00 +0300
Gregory Edigarov  wrote:

> On 14.10.16 22:48, Raul Miller wrote:
> > On Fri, Oct 14, 2016 at 2:50 PM, thrph.i...@gmail.com
> >  wrote:  
> >> " The only truly secure system is one that is powered off, cast in
> >> a block of concrete and sealed in a lead-lined room with armed
> >> guards - and even then I have my doubts."  
> > Powered off works surprisingly well for some other operating
> > systems. 
> well, not any more, in the presence of Intel AMT...

It's not just Intel either:
https://www.amd.com/en-us/innovations/software-technologies/security
Catering to low-level laziness at the expense of everyone who dares use
these chips.


There appears to be a niche market possibly emerging in Russia as
a result of this kind of thing.
http://russia-insider.com/en/technology/russias-next-generation-elbrus-8c-chips-be-ready-2016/ri7551
https://meduza.io/en/feature/2015/06/02/when-there-s-no-shame-in-made-in-russia

Disclaimer: do not ignore the possibility of Russian backdoors. Still,
it would be nice if they would ship it worldwide, we may even have
OpenBSD/elbrus.

Re: What are the security features in OpenBSD 6.0 that are by default disabled?

[bytevolcano]

On Fri, 14 Oct 2016 20:50:20 +0200
"thrph.i...@gmail.com"  wrote:

> or this kind...
> 
> " The only truly secure system is one that is powered off, cast in a
> block of concrete and sealed in a lead-lined room with armed guards -
> and even then I have my doubts. "
> 

It needs to be stored under a filing cabinet in a disused lavatory with
a sign on the door saying Beware of the Leopard.

Re: Booting BSD on a Libreboot system - documentation needed

[bytevolcano]

On Thu, 6 Oct 2016 15:05:04 +1100
Aaron Mason  wrote:

> Holy frijole, just reading some of the responses from the some people
> in GNU - I'm at the point where I'm not entirely convinced that GNU
> isn't a cult, with Stallman as the high almighty leader.

I am suspicious of both sides. Libreboot's team talks about
"transgender discrimination" of employees at GNU, without actually
explaining what went on over at GNU that was anything serious, or
anything "transgender" related.

The Libreboot side claims some people got fired just for being
transgender. I could not see anything more than just that claim, and a
list of employees who were "discriminated" against.

However, all the GNU side responses, as cult-ish as they are, are
somewhat valid if Leah and co have set the copyright to the FSF, in
which case there is no easy way out other than a fork. Leah and co have
to be careful, because have a look at this:
http://www.guidestar.org/FinDocuments/2007/412/165/2007-412165986-036368a0-9.pdf

As of writing this message, we are in the 2010's, where anyone and
everyone uses "(trans)gender discrimination" or "racial discrimination"
to avoid accountability. A little suspicion, cynicism, and scepticism
could reduce potential embarrassment.

Re: Cron logs in /var/cron/log instead of /var/log/cron?

[bytevolcano]

On Sun, 02 Oct 2016 22:45:00 -0600
"Theo de Raadt"  wrote:

> > Why is it in /var/cron/log and not /var/log/cron by default? To me
> > it makes more sense to have it all in /var/log/, but given it has
> > been the default for several years, is there a reason (other than
> > historic) that the default is like that?  
> 
> That dates back to more than 20 years actually.
> 
> Back in the CSRG days, a lot of new daemon imports got their own /var
> directories for reasons we can only guess at.

So it appears this is merely historic then.

> 
> > Is there any harm or issue with setting the log location
> > of cron logs to /var/log/cron instead, or is it best to leave it
> > in /var/cron/log?  
> 
> You can do whatever you want.
> 
> Before we talk about changing this, we must know what the downsides
> are.

Indeed; I was wondering whether there are any issues/downsides with
changing this. I have changed this for the last 5 years without any
adverse effects on my end, but I only have done this on about 8
different machines, with different purposes.

> 
> > I am interested to know as I keep /var/log in a separate UFS
> > partition mounted with rw,softdep,noatime,nodev,noexec,nosuid to
> > store all the syslog logs, and /var/cron/log is the odd one out
> > here.  
> 
> With softdep???  That is completely insane.  So clearly you don't
> actually care to have the contents of logs after a crash -- since
> softdep is quite likely to lose data buffers during circumstances like
> memory pressure, etc etc.
> 
> That's the kind of comment that leads me to take bug reports less
> seriously in the future... diagnostic logs which would have solved
> the problem, will have been lost INTENTIONALLY.  And then we get
> asked for help?  Crazy.
> 

Thank you for that information; The impression I got about softdep was
that it guarantees file system integrity so fsck is not needed.

I have softdep enabled on all the partitions as per this:
https://www.openbsd.org/faq/faq14.html#SoftUpdates
I guess it is time for me to evaluate my setup again.

Cron logs in /var/cron/log instead of /var/log/cron?

[bytevolcano]

I have noticed for the last 5 years of OpenBSD usage that the cron log
location is /var/cron/log, instead of /var/log/cron:

#   $OpenBSD: syslog.conf,v 1.19 2015/11/26 15:25:14 deraadt Exp $
#

*.notice;auth,authpriv,cron,ftp,kern,lpr,mail,user.none /var/log/messages
kern.debug;syslog,user.info /var/log/messages
auth.info   /var/log/authlog
authpriv.debug  /var/log/secure
cron.info   /var/cron/log

...

Why is it in /var/cron/log and not /var/log/cron by default? To me it
makes more sense to have it all in /var/log/, but given it has been the
default for several years, is there a reason (other than historic) that
the default is like that?

Is there any harm or issue with setting the log location
of cron logs to /var/log/cron instead, or is it best to leave it
in /var/cron/log?

I am interested to know as I keep /var/log in a separate UFS partition
mounted with rw,softdep,noatime,nodev,noexec,nosuid to store all the
syslog logs, and /var/cron/log is the odd one out here.

Re: LLVM license change

[bytevolcano]

On Tue, 27 Sep 2016 20:29:56 -0500
Amit Kulkarni  wrote:

> On Tue, Sep 27, 2016 at 8:06 PM, Chris Cappuccio 
> wrote:
> 
> > Ingo Schwarze [schwa...@usta.de] wrote:  
> > > Hi Benjamin,
> > >
> > > kbenjamin Coplon wrote on Mon, Sep 26, 2016 at 01:23:43PM -0400:
> > >  
> > > > What does the OpenBSD community think about the LLVM proposal
> > > > to move to the Apache license?
> > > >
> > > > http://lists.llvm.org/pipermail/llvm-dev/2016-September/104778.html  
> > >
> > > If LLVM would move to the Apache 2 license, we would become unable
> > > to use versions released after that change, and would be stuck
> > > with version released before the change, just like we are stuck
> > > with pre-GPLv3 gcc now.  So it would be very bad for us.
> > >
> > > See http://www.openbsd.org/policy.html :
> > >
> > >   Apache
> > > The original Apache license was similar to the Berkeley
> > > license, but source code published under version 2 of the Apache
> > > license is subject to additional restrictions and cannot be
> > > included into OpenBSD.
> > >
> > > In a nutshell, OpenBSD does not consider software released under
> > > Apache 2 to be free software.  At least not free enough for us.
> > >  
> >
> > One major problem with the Apache 2.0 license is the fact that it
> > is not merely a software license, but extends out into contract law.
> > This has been a concern with many licenses, not just Apache.
> >
> > If you use Apache 2.0 license code, you lose rights that you
> > otherwise retain under the MIT or BSD license.
> >
> > Just review sections 3 and 4. The patent clause in section 3 is an
> > issue.
> >
> > https://www.apache.org/licenses/LICENSE-2.0.txt
> >
> > Chris
> >
> >  
> Ironically, LLVM wants protection against patents.
> 

And that is because corporate "contributor-wannabes" put pressure on the
LLVM foundation.
http://lists.llvm.org/pipermail/llvm-dev/2015-October/091536.html

It does say "this is an RFC" but that was last year. We are now in this
year:
http://lists.llvm.org/pipermail/llvm-dev/2016-September/104778.html

What I particularly do not like is the "IANAL but let's do it anyway"
drift emanating from a lot of high profile developers there.

security.html

[bytevolcano]

Hello,

I have a suggestion to reduce the amount of maintenance work
necessary for errata.

Why not just have a link to errata.html on the security.html page,
instead of each releases' errata? Each releases' errata is already
accessible on the errata.html page anyway.

This is just a suggestion; whilst I think the current setup is easy to
navigate, I imagine this change above can save a some maintenance work
from the developer end.

Re: FW Hardware

[bytevolcano]

On Thu, 22 Sep 2016 15:29:12 -0400
Eike Lantzsch  wrote:

> or for a little more you get
> PC Engines APU.2C2
> which is amd64, has far more RAM and three Gigabit-ports.
> Interfaces: Realtek 8168

Or if you are patient, and need multiple SIM cards, you can wait for the
APU3a4 or 3a2: http://www.pcengines.ch/apu3a4.htm

> Look for a Bundle; it includes board, wallwart, memory-card and
> cabinet. Cabinet has lower profile than the one for ALIX, only 168 x
> 157 x 30 mm

It will help to buy the antennae as well.

Re: Dual booting - can't boot OpenBSD from Windows 10 bootloader

[bytevolcano]

Hi Eric,

On Fri, 23 Sep 2016 08:04:19 -0400
Eric Furman  wrote:

> NO professional dual boots OS's
Apart from those who are sick and tired of Windows, and sick and tired
of Microsoft controlling their PCs. Many a professional will use
Windows to do their work-related work, and the Linux distro to do the
rest of their stuff.

> There is NO REAL  reason to dual boot ANY OS's
See above, although with the event of vmm(4) and vmd(8) and other
virtualisation, I predict that eventually your point will be valid, as
people can simply run the secondary OS in a virtual environment.

> This is why OpenBSD has stopped supporting such nonsense.
Just because OpenBSD doesn't support it doesn't mean that it is "such
nonsense." However since there are plenty of other boot managers
out there, many of which support this configuration, there is no need
for OpenBSD's boot loader to support it, as this just duplicates work.

> Sorry.
> I AM NOT AN OPENBSD DEVELOPER
> NEVER HAVE BEEN
> NEVER WILL BE.
> http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/ports/geo/openbsd-developers/files/OpenBSD
Then there is no need to shout at everyone.

> On Fri, Sep 23, 2016, at 06:57 AM, Lampshade wrote:
> > I have installed OpenBSD before it had UEFI support,
> > so I installed in Legacy Boot mode (I have UEFI capable
> > laptop).
> > I personally use Grub2 installed via
> > debian live amd64 standard  image.
> > 
> > I don't have Gnu/Linux installed.
> > I only have bootloader from Debian.
> > 
> > I have Windows 8.1 and OpenBSD amd64.
> > 
> > # cat /mnt/ext2/grub/grub.cfg \   
> > > | grep -v -e ^#  -e ^[:space:]*$  
> > GRUB_DEFAULT=0
> > GRUB_TIMEOUT=5
> > GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
> > GRUB_CMDLINE_LINUX_DEFAULT="quiet"
> > GRUB_CMDLINE_LINUX=""
> > menuentry "Windows" --class os {
> >   set root=(hd0,2)
> >   chainloader (hd0,msdos2)+1
> > }
> > menuentry "OpenBSD" {
> >   set root=(hd0,4)
> >   chainloader +1
> > }
> > 
> > Grub2 is faster than Windows bootloader.  

Man page for md5(1)

[bytevolcano]

For md5(1) (and therefore, sha1(1), sha256(1), sha512(1)), the man page
has this:

"-q  Only print the checksum (quiet mode)."

Since this has the same behaviour as "cksum -q", would it be best to
keep it in line with it:

"-q Only print the checksum (quiet mode) or if used in
conjunction with the -c flag, only print the failed cases."

Re: Add a Theo fortune cookie

[bytevolcano]

Rather than going through all the trouble of mucking around with the
build of an existing application, why not make it a standalone program?

Before anyone here goes mad, I can't be bothered testing this; it is something
I conjured up in less than two minutes, and I personally do not have any use
for this program, nor am I suggesting it goes in base. This is just for fun.

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

#include 
#include 

static const char *talk[] = {
"Write more code.",
"Make more commits.",
"That's because you have been slacking.",
"slacker!",
"That's what happens when you're lazy.",
"idler!",
"slackass!",
"lazy bum!",
"Stop slacking you lazy bum!",
"slacker slacker lazy bum bum bum slacker!",
"I could search... but I'm a lazy bum ;)",
"sshutup sshithead, ssharpsshooting susshi sshplats ssharking 
assholes.",
"Lazy bums slacking on your asses.",
"35 commits an hour? That's pathetic!",
"Fine software takes time to prepare.  Give a little slack.",
"I am just stating a fact",
"you bring new meaning to the terms slackass. I will have to invent a 
new term.",
"if they cut you out, muddy their back yards",
"Make them want to start over, and play nice the next time.",
"It is clear that this has not been thought through.",
"avoid using abort().  it is not nice.",
"That's the most ridiculous thing I've heard in the last two or three 
minutes!",
"I'm not just doing this for crowd response. I need to be right.",
"I'd put a fan on my bomb.. And blinking lights...",
"I love to fight",
"No sane people allowed here.  Go home.",
"you have to stop peeing on your breakfast",
"feature requests come from idiots",
"henning and darren / sitting in a tree / t o k i n g / a joint or 
three",
"KICK ASS. TIME FOR A JASON LOVE IN!  WE CAN ALL GET LOST IN HIS HAIR!",
"shame on you for following my rules.",
"altq's parser sucks dead whale farts through the finest chemistry 
pipette's",
"screw this operating system shit, i just want to drive!",
"Search for fuck.  Anytime you see that word, you have a paragraph to 
write.",
"Yes, but the ports people are into S",
"Buttons are for idiots.",
"We are not hackers. We are turd polishing craftsmen.",
"who cares.  style(9) can bite my ass",
"It'd be one fucking happy planet if it wasn't for what's under this 
fucking sticker.",
"I would explain, but I am too drunk.",
"you slackers don't deserve pictures yet",
"Vegetarian my ass",
"Wait a minute, that's a McNally's!",
"don't they recognize their moral responsibility to entertain me?",
"#ifdef is for emacs developers.",
"Many well known people become net-kooks in their later life, because 
they lose touch with reality.",
"You're not allowed to have an opinion.",
"tweep tweep tweep",
"Quite frankly, SSE's alignment requirement is the most utterly 
retarded idea since eating your own shit.",
"Holy verbose prom startup Batman.",
"Any day now, when we sell out.",
"optimism in man kind does not belong here",
"First user who tries to push this button, he pounds into the ground 
with a rant of death.",
"we did farts.  now we do sperm.  we are cutting edge.",
"the default configuration is a mixture of piss, puke, shit, and bloody 
entrails.",
"Stop wasting your time reading people's licenses.",
"doing it with environment variables is OH SO SYSTEM FIVE LIKE OH MY 
GOD PASS ME THE SPOON",
"Linux is fucking POO, not just bad, bad REALLY REALLY BAD",
"penguins are not much more than chickens that swim.",
"i am a packet sniffing fool, let me wipe my face with my own poo",
"Whiners.  They scale really well.",
"in your world, you would have a checklist of 50 fucking workarounds 
just to make a coffee.",
"for once, I have nothing to say.",
"You have no idea how fucked we are",
"You can call it fart if you want to.",
"wavelan is a battle field",
"You are in a maze of gpio pins, all alike, all undocumented, and a few 
are wired to bombs.",
"And that is why humppa sucks... cause it has no cause.",
"cache aliasing is a problem that would have stopped in 1992 if someone 
had killed about 5 people who worked at Sun.",
"Don't spread rumours about me being gentle.",
"If municipal water filtering equipment was built by the gcc 
developers, the western world would be dead by now.",
"kettenis supported a new machine in my basement and all I got to do 
was fix a 1 character typo in his html page commit.",
"industry told us a lesson: when you're an asshole, they 

Re: doas.conf, no persist option in 6.0 Release

[bytevolcano]

On Tue, 13 Sep 2016 10:28:56 -0400
Eike Lantzsch  wrote:

> On Dienstag, 13. September 2016 06:46:04 PYT jungle Boogie wrote:
> > On 13 September 2016 at 05:55, Eike Lantzsch 
> > wrote:  
> > > but in man doas.conf of 6.0 Release it is not mentioned and using
> > > that option rightly results in a syntax error if used.  
> > 
> > It's not in -release.
> > 
> > If you take a look here:
> > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/doas/doas.c?r1=1.64
> > 
> > You'll notice doas has been modified after -release was made.  
> 
> Well, I noticed that but not this on undeadly.org:
> "See his flak entry for the full story (and bear in mind he's
> referring to - current at the time of writing)."
> duh ...
> sorry for the noise
> 

I have noticed undeadly.org often delays things. When an
OpenBSD-related event occurs, expect it to appear on undeadly.org no
earlier than 5-6 days later.

Re: OpenBSD 6.0 release and errata60.html

[bytevolcano]

Hello Andreas,

On Fri, 2 Sep 2016 12:29:28 +0200
Andreas Kusalananda Kähäri  wrote:

> On Fri, Sep 02, 2016 at 11:33:59AM +0200, Alexander Hall wrote:
> > On Thu, Sep 01, 2016 at 03:03:15PM -0400, Daniel Ouellet wrote:
> > > On 9/1/16 2:59 PM, R0me0 *** wrote:
> > > > Hello misc,
> > > >
> > > > I have a little doubt
> > > >
> > > > Today was a Official Release of 6.0
> > > >
> > > > This release already include errata60.html patches or I need to
> > > > apply ?
> > >
> > > Yes you need to apply the patch.
> > >
> > > The release was done long ago already it was release to the public
> > > today. Takes time to get all piece together you know.
> > >
> > > Might be more welcome to say thanks to the devs instead don't you
> > > think?
> >
> > So instead of asking "How does this work?" he should say
> > "Thanks!" (and still not know how it works)?
> >
> > I don't see the connection. It was just a question, and at least I
> > could not read anything extra into it.
> >
> > /Alexander
>
> I think it's the use of the word "doubt" ("a feeling of uncertainty or
> lack of conviction").
>
> I have noticed that some people tend to use "I have a doubt" with the
> meaning "I have a question/issue/problem".  This is different from
> "I'm doubting" which means "I have no confidence in" or "I'm
> questioning".
>

I think it is important to note here that not everyone speaks fluent
English. I think a huge problem within mailing lists in general is the
tendency for people to gang up and focus on petty wording issues, and
associating "attitude" or "tone" with words, focusing on the point
of a post itself.

Re: DigitalOcean and OpenBSD

[bytevolcano]

andrew fabbro wrote:
...

- some day in the bright shining future when vmm is done, you may be able
to buy an OpenBSD guest VM on an OpenBSD host...and then these piddling
Amazon and Microsoft Azure empires will fall as Puffy storms the net.  To
the cloud!



Those "piddling Microsoft Azure empires" may not be the best in software 
development, but they are better at marketing than the OpenBSD team is, 
by several orders of magnitude. And much more aggressive too.


I wouldn't get your hopes up, even if vmm was capable of running 
complete Windows 10+, Linux, BSD, and MacOS X installations (even if 
just with a little help from a ported QEMU) by 2018.


The best doesn't always win out when it comes to marketing and 
mainstream/consumer use. Puffy won't be "storming the net" any time soon.

Re: thunderbird segfaults

[bytevolcano]

Stefan Wollny wrote:

Hi Theo!


Gesendet: Montag, 08. August 2016 um 17:21 Uhr
Von: "Theo Buehler" 
An: misc@openbsd.org
Betreff: Re: thunderbird segfaults


disklayout:
a: 5122.2M   /
b: 1019.8M   swap
d:   10244.6M   /tmp
e:   15359.0M   /var
f:30718.0M  /usr
g: 914285.1M/home

/usr is mounted read-only
/var is mounted no-exec


So much space and no separate /usr/local ? why?


Lazyness :-) and not being a developer I find it suitable for my needs 
(flexibility with growing needs under /usr ): If _really_ necessary (about once 
in 2 years) I simply install everything fresh but /home.


That's some kind of "laziness" there; you have to spend extra effort to 
get the installer to partition your drive like that, since it adds both 
/usr and /usr/local by default. ;)


Also, there's almost 30GB allocated to it. You could have allocated 10GB 
to /usr and the rest to /usr/local and you'd be good enough to install a 
few dozen packages at least.





If this is really the case, please make sure /usr is mounted wxallowed,
see https://www.openbsd.org/faq/upgrade60.html


Yes - it is mounted wxallowed (Janne@ was the very first today to ask this).


On that note, is there a list of ports/packages that needs wxallowed (or 
any way to obtain such a list)? It would be rather a shame if you only 
had packages that don't need wxallowed (eg. gateway, server) and that 
wxallowed option is sitting on the file system.

Re: tp-link tl-wn722n athn0: could not load firmware

[bytevolcano]

Mihai Popescu wrote:

Had anyone any success with this usb wireless in recent snapshots.

Following some hints that this chip is not properly powered from USB
port, I hardwired it to the power supply of the computer, but the
result is the same: it fails to load the firmware.

Nevertheless I had some interesting results using some custom usb
cable prepared for some measurements. After a few plug-in actions, the
500mA fuse of my multimeter was destroyed. It looks like there is a
current spike at plug-in time, greater thatn 500mA.
But, switching to a bigger scale and moving the usb wireless module on
another OS, I got aprox. 130mA current draw in a working state.

I tried to recompile the 5.9 release kernel with some added delays in
the code, but I got some errors like syscal 114 and another numbers at
boot time.


It sounds more like a capacitor charging up within the device. Seems a 
bit weird for a wireless module, but I guess this could be a decoupling 
cap. If your 500mA fuse blew the first time you plugged it in but not 
the second time, it was just drawing the current to charge some 
capacitor up.


Then when you plugged it into another OS, the cap was already 
(partially) charged, so the current spike was not as large, or as long. 
A spike that is too short will not blow a fuse, even if it is a 
fast-blow one, unless the current is much higher than the fuse itself. A 
fuse is really designed to protect against situations which could result 
in overheating of the conducting paths (wires, PCB tracks, etc).


Maybe try again after shorting the power pins on the USB plug on the 
wireless adapter for a few seconds (or better yet, instead of a short, 
use a bleed resistor of something like 10ohms to discharge the cap).



An oscilloscope is great for picking up such transients, since a 
multimeter typically has a latency for registering these kinds of 
transients.


Something like:

+--[scope]-+
GND-> | | <- Probe
| |
(-) --+--[1R0]---+-[LOAD] (+)

Re: Weird cursor problem

[bytevolcano]

Greetings Anton,

On Wed, 3 Aug 2016 03:36:39 +0300
li...@wrant.com wrote:

> Wed, 3 Aug 2016 07:10:51 +1000 bytevolc...@safe-mail.net
> > > ...
> > 
> > It still happens regularly on 5.9 (with all errata up to and
> > including July applied) as well. I felt that this was quite random
> > actually and there was no real explanation for it.
> > 
> > This occurs with either Firefox or Seamonkey open, but it will
> > happen randomly (such as when trying to select text from xterm, for
> > example).
> > 
> > On another note, I also find it strange that there is no X
> > -configure option; I am trying to configure my touch pad to disable
> > the annoying tap-to-click feature; I feel this is partially the
> > culprit in my case.  
> 
> Hi bytevolcano,
> 
> Could be, could be not..  I run latest snapshots (always), and have
> too seen similar, so below are some silly tips to handle touchpad &
> pointer affecting programs, that may be interfering with your daily
> zen routine.

I am certain that, whilst it is not strictly the culprit, its behaviour
in relation to the double-tap-to-click feature is certainly aggravating
it; I am also thinking this may have to do with the fact that I am not
used to the whole doubletap-to-click paradigm.

> 
> This is not a complaint at OpenBSD, only a suggestion to test
> synaptics. I love using Xorg in OpenBSD and am actually very happy
> with "my" setup. Here we go, you may now delete this message quick,
> no useful info below:
> 
> I've also seen an incorrect pointer icon sporadically (quite rarely)
> instead of the expected one on my laptop when I moved the mouse over
> the with synergy (in ports), and always wondered why this happens. I
> enable tap to click in my X session initialisation script .xinitirc:
> 
> $ grep syncl .xinitrc
> DISPLAY=:0 synclient TapButton1=1 TapButton2=3 TapButton3=2
> 
> You can disable this feature by setting the respective variables to 0
> in your session start up.  Or respectively adding a section in your X
> configuration (or part of it) file.  For example:
> 
> DISPLAY=:0 synclient TapButton1=0 TapButton2=0 TapButton3=0
> 
> I am not sure however this is what causes the problem, though.  It may
> be missing pointer icon from the sets, a program trying to weird stuff
> or incorrectly carried information by the synergy application, dunno..
> 
> Here are the options to experiment with in xorg.conf, or in .xinitrc
> 
> synaptics - touchpad input driver
> [http://man.openbsd.org/synaptics]
> 
> synclient - command line utility to query and modify Synaptics driver
> [http://man.openbsd.org/synclient]
> 
> I've actually not needed any X configuration file for a long long time
> and indeed prefer to set everything either via command line utilities,
> or not bother AT ALL with xorg.conf, due to session loss to manage it.
> 
> There is also a little utility to help with touchpad accidental moves
> during kbd typing on one of those laptop where it's too easy to do so:
> 
> syndaemon - monitors keyboard activity and temp disables the touchpad
> [http://man.openbsd.org/syndaemon]
> 
> $ grep synd .xinitrc
> DISPLAY=:0 syndaemon -i 1 -d
> 
> What I "need" (this decade!) from Xorg is to implement internally some
> capabilities like those provided by the synergy program.  These should
> allow using the keyboard and mouse on one machine to interact with the
> screens on multiple machines over Xorg internal protocol AND see it on
> their respective monitors (don't give me that KVM $@#! nonsense).  So,
> then we'll not need potentially flawed in multiple ways external tools
> for what Xorg should have given oh so many years ago already (no *NC).
> 
> Well, whatever, the important thing is that for now, you could further
> experiment and try to catch the odd behaviour in X pointers.  I guess,
> there is scientific method in this, but I don't have the time now too.
> That'd be: watch logs, dump stats from events and see what happens by
> tracing internally Xorg sections ..should be a way to do it properly..
> 
> Hope this helps (or gives ideas), if not, please excuse the "outflow".
> 
> Picture of several men at a conference explaining a minor tech glitch.
> [http://9front.org/img/pleaseexcusemetheoutflow.front.png]
> 
> Kind regards,
> Anton
> 

It would be helpful if I could get the synaptics driver running first. ;)
The problem is I am unsure what kind of driver my touchpad uses, and
xinput reveals this:

$ xinput
+ Virtual core pointer  id=2[master pointer  (3)]
|   + Virtual core XTEST pointerid=4[slave pointer  (2)]
|   + /dev/wsmouse 

Re: Weird cursor problem

[bytevolcano]

Philip Guenther wrote:

On Tue, Aug 2, 2016 at 8:12 AM, Alan Corey  wrote:

Anybody else see this?  It's happening at least 6 times a day, it's a
little annoying.  It's happened a few times on my laptop (same 5.7
i386).  It does happen without Firefox open but most of the time
that's open anyway so I've only caught the cursor problem without
Firefox a few times.  Ctrl and any arrow gets out of it.


I remember having firefox snag a server grab like that in the past,
but that was a long while ago.  5.7 is out of support now; no one's
going to dig in its source when two releases have come out since then
and another will out in a month.  Upgrade to at least 5.9, or better,
upgrade to 6.0 and report whether it's still a problem.

Philip Guenther



It still happens regularly on 5.9 (with all errata up to and including 
July applied) as well. I felt that this was quite random actually and 
there was no real explanation for it.


This occurs with either Firefox or Seamonkey open, but it will happen 
randomly (such as when trying to select text from xterm, for example).


On another note, I also find it strange that there is no X -configure 
option; I am trying to configure my touch pad to disable the annoying 
tap-to-click feature; I feel this is partially the culprit in my case.

Re: tmpfs

[bytevolcano]

Marc Espie wrote:

On Tue, Aug 02, 2016 at 02:53:43AM -0400, Eric Furman wrote:

...


Nope, I'm rather sure Theo doesn't care one way or the other.

I'm one of the guys who would very much like working tmpfs. Actually, it
has worked "good enough for me", but there are a few issues at work.

- I lack the time needed to fully dive into the kernel part.
- naddy did say multiple times it doesn't go all that fast compared to ffs
with ssd (well, I don't have a ssd on my build machines, so tmpfs is
marginally faster)
- there are loads of small nits in it that should properly be fixed.

Admittedly, I think a few good things came out of tmpfs. I've seen the fixes
(dabbled) for some of the problems, and in at least one case, the argument
check was moved up into the VFS layer.

In reality, every time I look at the VFS kernel layer, I get side-tracked
into thinking this is horrible code (the marshalling/unmarshalling of
parameters is very unnecessary, and doing pseudo inheritance by hand at the
function pointer level is horrible... there's a huge amount of weird
duplicated code  in there... having three vfs structs for each fs based on
the type of file (normal file or otherwise) is rather strange, and I'm
reasonably certain some of the failure mode is dubious at best.


That said, it's on my long long list of things to try to play more with
eventually... but that list gets longer everyday, and Theo and other people
tend to add "priority" items to it that trump my ventures into kernel-land...



Well, tmpfs certainly lived up to its name. Introduced in 5.5 only to be 
disabled in 6.0, there couldn't have been a more temporary file system.

Re: tmpfs

[bytevolcano]

mxb wrote:

...


For someone who "doesn't use tmpfs" or "doesn't care that much" about 
it, you sure are making a racket on this thread.

Re: ratble and rdomain support on dhcpd and openvpn

[bytevolcano]

Kapetanakis Giannis wrote:

On 15/07/16 22:34, Difan Zhao wrote:

Thank you sir! So I probably just stick with my hacking approach and
wait for
the 6.0. I see that will come in November so not too much waiting.

So any idea how the openvpn might start to support rtable or rdomain?

Thanks,
Difan



OpeBSD -current (snapshots) is quite stable.
I would suggest you try it and don't wait for the next release.

G



Be careful though; the API/ABI in -current is essentially a moving 
target, so if you do want to stick to -current, be certain the packages 
you run are downloaded roughly the same date you download the snapshot.


Running -current vs -release/-stable should be considered on a 
case-by-case basis. If you know exactly what packages you expect to run, 
and are likely to keep that set, then -current is for you.

Re: shm_mkstemp(3) without the file name

[bytevolcano]

Philip Guenther wrote:


Well, I am amazed. I guess I just have to do some more investigation into
workarounds for this, as RAM-based tmpfs file systems will get full very
quickly with shared memory segments, and large segments result in high disk
activity when munmap() is called. And SysV shared memory is too limiting for
my purposes.


Could you clarify what underlying problem you're trying to solve?
Maybe there's just a misunderstanding about the POSIX APIs, or about
how OpenBSD implements them, or what alternative APIs exist.


Philip Guenther



Basically:

1. shm_mkstemp() will result in the creation of a file with a long 
random name in /tmp, which is quite small on the target system (512M 
mfs). The system has 4GB of RAM.


 - The buffers tend to be somewhat large (several dozen MB 
occasionally). I cannot create a shared memory segment larger than the 
remaining free space on the /tmp FS. This creates an issue where 
multiple applications have a buffer each.


 - On a system where /tmp is a disk partition, this file does not 
actually occupy any space until munmap() is called; this results in a 
long pause as it writes the data to the disk.
   This occurs even if shm_unlink() is called before the unmap/close. 
In fact, shm_unlink() is called immediately after shm_mkstemp(), because 
I only am interested in the descriptor from now on. This disk write is 
unnecessary for shared memory; I don't want the file to persist at all. 
When both the application and server are done with the buffer, all 
should be gone.


 - The only way to resolve the issue with disk I/O is to call 
ftruncate(fd, 0) before munmap(), and even this only works where /tmp is 
a huge MFS partition or a huge disk partition.


 - There is a brief point in time (between shm_mkstemp() and 
shm_unlink()) where a rogue application can grab the buffer file, call 
ftruncate(), and map its contents, without either my server or 
applications knowing. Whilst file permissions are good at stopping other 
users accessing the segment, this goes against the idea that the app


To summarise, the major issue I am having is that the "shared memory" 
buffer looks like a file on disk, and acts like a file on disk, rather 
than a section of memory that I am sharing in between processes. As a 
result, I need to have a huge /tmp file system just to accommodate the 
buffer, regardless of how much RAM I have.



The problem I have with the SysV shm* API is that it gets hard to clean 
up shared memory segments. Whilst that I can live with to some degree, 
the biggest issue with it is the 32MB limit per segment 
(kern.shminfo.shmmax).

Re: shm_mkstemp(3) without the file name

[bytevolcano]

Ted Unangst wrote:

bytevolc...@safe-mail.net wrote:

I see where you are coming from, but what I am getting at is, where in
the POSIX standard does it say that it needs to be anywhere in the file
system at all? If it is shared memory, then surely this doesn't require
backing up.


Oh. It doesn't have to be a file. It can be a file. (And you can't asusme it's
not a file.)



Well, I am amazed. I guess I just have to do some more investigation 
into workarounds for this, as RAM-based tmpfs file systems will get full 
very quickly with shared memory segments, and large segments result in 
high disk activity when munmap() is called. And SysV shared memory is 
too limiting for my purposes.

Thanks for the info, Ted.

Re: shm_mkstemp(3) without the file name

[bytevolcano]

Theo de Raadt wrote:

Is using ftruncate(2) to lengthen the segment the right way to do it, or
is this yet another stupid limitation of POSIX shared memory?


If you are getting the picture that the standards commitee cobbled
together a bunch of junk and expected a good outcome, you are well
on your way to being on the same page as us...



I agree. It all makes me wonder how long we have before IPv6 support is 
mandated for UNIX domain sockets.

Re: shm_mkstemp(3) without the file name

[bytevolcano]

Ted Unangst wrote:

bytevolc...@safe-mail.net wrote:

When I use ftruncate(2) to actually allocate the segment, the file is as
long as the segment that is allocated.

Even if the file is unlinked before ftruncate(2) is called, enough free
space in the /tmp *file system* is required for the shared memory segment.

Is using ftruncate(2) to lengthen the segment the right way to do it, or
is this yet another stupid limitation of POSIX shared memory?


ftruncate is really the only way to do it.

There's nothing special about shm_open. It's just open with a different name.
If you want the files on a different filesystem, you can use open.



I see where you are coming from, but what I am getting at is, where in 
the POSIX standard does it say that it needs to be anywhere in the file 
system at all? If it is shared memory, then surely this doesn't require 
backing up.

Re: shm_mkstemp(3) without the file name

[bytevolcano]

Ted Unangst wrote:

bytevolc...@safe-mail.net wrote:

Yes, it seems to create files with long names (that have nothing to do
with the template I provide) in the /tmp root.

If it doesn't respect the path or template, what is the point of having
this argument there in the first place, and what is the point of even
having a file on the file system?


The file is the backing for the memory. The path is so that you can refer to
the same object. There's no requirement that the path be the name of the file
in the filesystem, since you don't use normal file functions to talk to it.


When I use ftruncate(2) to actually allocate the segment, the file is as 
long as the segment that is allocated.


Even if the file is unlinked before ftruncate(2) is called, enough free 
space in the /tmp *file system* is required for the shared memory segment.


Is using ftruncate(2) to lengthen the segment the right way to do it, or 
is this yet another stupid limitation of POSIX shared memory?
I did give SysV shared memory segments a go, but work required for 
cleanup is even more insane when the program crashes!





I do not see any promises here. The only promise here is that the shared
memory object will be created atomically. I found it creates long-name
files with mode 0600. If the implementation promises these permissions
for shm_mkstemp(3), then fantastic; it should really be mentioned in the
man page though.


"This implementation forces the mode to be 0600"


Thanks for pointing that out; I saw that, but I got confused as it was 
in the paragraph describing shm_open(3).





There's still an issue of the stale files on the file system, should
there be a crash, interruption, signal, or something like that. Even
with close(2), the file remains until shm_unlink(3) is called.


That's not unique to shm functions. Everything creating files can do that.



Indeed, but I don't see a use case for having shared memory backed 
verbatim by a file, to the point where the amount of shared memory that 
can be allocated depends on how much free space left in the /tmp file 
system.


Say I want to allocate 2GB shared memory object, I cannot do so with 
ftruncate(2) because I only have 128MB left in /tmp.

Re: shm_mkstemp(3) without the file name

[bytevolcano]

Jeremie Courreges-Anglas wrote:

bytevolc...@safe-mail.net writes:


Hello,

I am writing a local server which requires the use of shared memory
objects. Essentially, other applications communicate to this server by
connecting to a UNIX domain socket within the file system.

Occasionally such an application may require a shared memory buffer to
share large quantities of information with the server. In doing this,
the server uses shm_mkstemp(3) to create the shared memory objects, and
then sends the file descriptor over the connection.

char snm[25] = "/tmp/megaserv/XX";


I doubt that our shm_open(3) implementation will respect the path you
provide here.


Yes, it seems to create files with long names (that have nothing to do 
with the template I provide) in the /tmp root.


If it doesn't respect the path or template, what is the point of having 
this argument there in the first place, and what is the point of even 
having a file on the file system?





int fd;

fd = shm_mkstemp(snm);

/* Error handling omitted for clarity. */
/* Potential race condition here */

shm_unlink(snm);

...

/* Send fd over connected socket. */

Whilst the setup I have works well, I see a potential race condition,
albeit a very small one, in the position indicated above; an external
process, malicious or otherwise, can connect to the object in between
the shm_mkstmp() and shm_unlink() calls.


Not if the permissions on the file prevent this.

  "This implementation forces the mode to be 0600 or 0400, and prohibits
  sharing between different UIDs."


Furthermore, there is a small possibility for a stale file to be present
in the file system, should there be a crash.


Why not trust the promise made by shm_mkstemp(3)?


" If a temporary shared memory object is desired, the shm_mkstemp() 
function should be preferred as it avoids several possible security 
holes that tend to appear in programs trying to create their own unique 
temporary names.  The template argument is a string with at least six 
trailing Xs as described in mkstemp(3)."


I do not see any promises here. The only promise here is that the shared 
memory object will be created atomically. I found it creates long-name 
files with mode 0600. If the implementation promises these permissions 
for shm_mkstemp(3), then fantastic; it should really be mentioned in the 
man page though.


But I suppose if the malicious process is running as the user, then it 
can wreak all kinds of other havoc on the system; no need to protect the 
shared memory buffers then.


There's still an issue of the stale files on the file system, should 
there be a crash, interruption, signal, or something like that. Even 
with close(2), the file remains until shm_unlink(3) is called.





Is there a way of creating these objects without having to actually
create a file in the file system, something like pipe() or socketpair()?

For example:

int shm_create(int flags);

That would basically eliminate the race condition, the possibility of
a stale object, and make shm_unlink() unnecessary in this case.

Any advice/suggestions?

shm_mkstemp(3) without the file name

[bytevolcano]

Hello,

I am writing a local server which requires the use of shared memory 
objects. Essentially, other applications communicate to this server by 
connecting to a UNIX domain socket within the file system.


Occasionally such an application may require a shared memory buffer to 
share large quantities of information with the server. In doing this, 
the server uses shm_mkstemp(3) to create the shared memory objects, and 
then sends the file descriptor over the connection.


char snm[25] = "/tmp/megaserv/XX";
int fd;

fd = shm_mkstemp(snm);

/* Error handling omitted for clarity. */
/* Potential race condition here */

shm_unlink(snm);

...

/* Send fd over connected socket. */

Whilst the setup I have works well, I see a potential race condition, 
albeit a very small one, in the position indicated above; an external 
process, malicious or otherwise, can connect to the object in between 
the shm_mkstmp() and shm_unlink() calls.


Furthermore, there is a small possibility for a stale file to be present 
in the file system, should there be a crash.


Is there a way of creating these objects without having to actually 
create a file in the file system, something like pipe() or socketpair()?


For example:

int shm_create(int flags);

That would basically eliminate the race condition, the possibility of a 
stale object, and make shm_unlink() unnecessary in this case.


Any advice/suggestions?

Re: How make "pkg_add" auto-choose some package version for me when same package is available in more versions?

[bytevolcano]

On Tue, 05 Jul 2016 10:12:01 +0800
Tinker  wrote:

> Wait, can "%" be used to install the latest version for unimportant 
> packages?
> 
> Or at least make pkg_add choose *some* version for me because I
> totally don't care, this would just be a trick to automate system
> installation more -
> 
> The *oldest* version would be fine too!
> 

If you don't want it to ask, just find the one in the index at your
local FTP mirror, and use its exact name. In all years I've been using
OpenBSD, I've not had the exact name (eg. fidgety-0.192.44p0) change
once in the -stable releases.

And what is an "unimportant package" anyway? What is "unimportant" to
you may be valuable to someone else.

Re: where is the image of openbsd arm ?

[bytevolcano]

On Fri, 24 Jun 2016 06:32:33 +0300
li...@wrant.com wrote:

> Fri, 24 Jun 2016 12:10:11 +1000 
> > On Fri, 24 Jun 2016 04:30:39 +0300
> > li...@wrant.com wrote:  
> > > 
> > > What is more important is the level of engineering information
> > > available from the manufacturer (PC Engines) web site including
> > > tech specs, manual, BIOS updates, accessories, enclosures, diag
> > > boards and also: Schematics!
> > 
> > I certainly dig schematics! Don't forget, they use coreboot.  
> 
> Yes, these are block diagrams of important sub-systems with chip
> pin-outs, signal names, voltages, logic arrangement.  It's not the
> complete electric schematic diagram as in a service manual, and
> certainly not system design documentation, but is is engineering
> level sufficient and: public access!

The schematic here (http://pcengines.ch/schema/apu2c.pdf) actually has
many of the the components too (mostly the support components around
the chips, and power regulators and filters), but they are "joined"
with the corresponding signal pins.

But as you say, engineering level sufficient and public access;
definitely a win.

I mentioned coreboot mainly because it is great to have hardware that
comes with it pre-installed, so it is essentially a guarantee that it
works.

> 
> Comparing this to the paper manual I got with my expensive 2011 Atom
> D525 system board from SuperMicro, I found what I got lacking for my
> engineers purpose, despite having connector pin-outs and some
> voltages.  Also, some time later I found out much cheaper Atom
> mini-ITX boards form competitors as a whole, I would have went with a
> PC Engines if I knew about them then.

I originally held off on PC Engines because they only had 100Mbps
connections at the time, and the specs were somewhat mediocre. The APU1
came in, but it only had a dual-core CPU and I have heard horror
stories about it heating up a lot.

Then the APU2 came in, and it was difficult to refuse; 1GHz quad-core,
4GB RAM, USB 3.0, supports OpenBSD, and 100% open source and
public-access schematic. And best of all, it means I can finally have a
modern system that doesn't have UEFI, which seems avoidable in laptops
these days unfortunately.

> 
> So, are you saying that coreboot is serial compatible BIOS?  As in
> textual interface exposed on the serial port, and no menu like the
> other historic Award/Phoenix/Ami PC BIOS-es?  Does it give access to
> all the BIOS options over the serial port as in pre-boot system set
> up via RS-232?  None video and keyboard dependencies any more for
> complete system management?  Is it?

This one is ASCII only, and doesn't appear to use any funny control
codes to juggle text around the screen and move the cursor all over
the place; if it does use control characters, then they are very
basic ASCII ones for presentation.

Though I am not sure if this is vanilla Coreboot; it would have been
modified to suit the hardware.

There is a "menu", but it's one of those "type the number of the item
you wish to enter" menus. The only options I could see are the boot
device order and a few settings here and there.

The general attitude of this BIOS is "load the OS and get out of the
way", which is how it should be.

> 
> > > 
> > > This seems to be by far more friendly to both engineer & consumer
> > > users.
> > > 
> > > PC Engines APU2 product line
> > > [http://www.pcengines.ch/apu2b2.htm]
> > > 
> > > 1) How do the APU systems go as pricing to comparable systems from
> > > other similar (industrial class, desktop enclosure)
> > > manufacturers?
> > 
> > I have two APU2C4 boards.  
> 
> I've never seen these in action, nor had chance to use any coreboot
> device.

I don't think this is has vanilla coreboot software on it either, given
that it only has a serial port and no video output. This is the only
coreboot device I have used.

> 
> > The price is not bad, and the ALIX/APU boards are not loaded with
> > consumer-grade "ooh, aah" bullet-point rubbish, unlike some of the
> > VIA boards which are (quite worryingly) also marketed towards
> > medical devices.  
> 
> The SuperMicro BIOS experience over serial port (the -F models have a
> BMC/IMPI controller onboard) is not that great.  It is the traditional
> Award style BIOS transposed in a screen interface 1:1 without a proper
> serial connection functionality factored in.  It is not a serial BIOS,
> it is serial exposed historic old school BIOS.  Not necessarily bad,
> it has borders, colours, much like servers from other commercial
> vendors.

This BIOS is 100% text-based, and it is a "what goes out stays out"
approach as far as its UI is concerned. In my opinion, every single
BIOS should be like this.

Basically you need to make sure the serial console is connected before
starting the system up, otherwise you'll end up missing the BIOS setup
menu and the system will either be in the 10 second delay (that allows
you to make a selection before it boots into the OS), or it 

Re: where is the image of openbsd arm ?

[bytevolcano]

On Fri, 24 Jun 2016 06:32:33 +0300
li...@wrant.com wrote:

> Fri, 24 Jun 2016 12:10:11 +1000 
> > On Fri, 24 Jun 2016 04:30:39 +0300
> > li...@wrant.com wrote:  
> > > 
> > > What is more important is the level of engineering information
> > > available from the manufacturer (PC Engines) web site including
> > > tech specs, manual, BIOS updates, accessories, enclosures, diag
> > > boards and also: Schematics!
> > 
> > I certainly dig schematics! Don't forget, they use coreboot.  
> 
> Yes, these are block diagrams of important sub-systems with chip
> pin-outs, signal names, voltages, logic arrangement.  It's not the
> complete electric schematic diagram as in a service manual, and
> certainly not system design documentation, but is is engineering
> level sufficient and: public access!

The schematic here (http://pcengines.ch/schema/apu2c.pdf) actually has
many of the the components too (mostly the support components around
the chips, and power regulators and filters), but they are "joined"
with the corresponding signal pins.

But as you say, engineering level sufficient and public access;
definitely a win.

I mentioned coreboot mainly because it is great to have hardware that
comes with it pre-installed, so it is essentially a guarantee that it
works.

> 
> Comparing this to the paper manual I got with my expensive 2011 Atom
> D525 system board from SuperMicro, I found what I got lacking for my
> engineers purpose, despite having connector pin-outs and some
> voltages.  Also, some time later I found out much cheaper Atom
> mini-ITX boards form competitors as a whole, I would have went with a
> PC Engines if I knew about them then.

I originally held off on PC Engines because they only had 100Mbps
connections at the time, and the specs were somewhat mediocre. The APU1
came in, but it only had a dual-core CPU and I have heard horror
stories about it heating up a lot.

Then the APU2 came in, and it was difficult to refuse; 1GHz quad-core,
4GB RAM, USB 3.0, supports OpenBSD, and 100% open source and
public-access schematic. And best of all, it means I can finally have a
modern system that doesn't have UEFI, which seems avoidable in laptops
these days unfortunately.

> 
> So, are you saying that coreboot is serial compatible BIOS?  As in
> textual interface exposed on the serial port, and no menu like the
> other historic Award/Phoenix/Ami PC BIOS-es?  Does it give access to
> all the BIOS options over the serial port as in pre-boot system set
> up via RS-232?  None video and keyboard dependencies any more for
> complete system management?  Is it?

This one is ASCII only, and doesn't appear to use any funny control
codes to juggle text around the screen and move the cursor all over
the place; if it does use control characters, then they are very
basic ASCII ones for presentation.

Though I am not sure if this is vanilla Coreboot; it would have been
modified to suit the hardware.

There is a "menu", but it's one of those "type the number of the item
you wish to enter" menus. The only options I could see are the boot
device order and a few settings here and there.

The general attitude of this BIOS is "load the OS and get out of the
way", which is how it should be.

> 
> > > 
> > > This seems to be by far more friendly to both engineer & consumer
> > > users.
> > > 
> > > PC Engines APU2 product line
> > > [http://www.pcengines.ch/apu2b2.htm]
> > > 
> > > 1) How do the APU systems go as pricing to comparable systems from
> > > other similar (industrial class, desktop enclosure)
> > > manufacturers?
> > 
> > I have two APU2C4 boards.  
> 
> I've never seen these in action, nor had chance to use any coreboot
> device.

I don't think this is has vanilla coreboot software on it either, given
that it only has a serial port and no video output. This is the only
coreboot device I have used.

> 
> > The price is not bad, and the ALIX/APU boards are not loaded with
> > consumer-grade "ooh, aah" bullet-point rubbish, unlike some of the
> > VIA boards which are (quite worryingly) also marketed towards
> > medical devices.  
> 
> The SuperMicro BIOS experience over serial port (the -F models have a
> BMC/IMPI controller onboard) is not that great.  It is the traditional
> Award style BIOS transposed in a screen interface 1:1 without a proper
> serial connection functionality factored in.  It is not a serial BIOS,
> it is serial exposed historic old school BIOS.  Not necessarily bad,
> it has borders, colours, much like servers from other commercial
> vendors.

This BIOS is 100% text-based, and it is a "what goes out stays out"
approach as far as its UI is concerned. In my opinion, every single
BIOS should be like this.

Basically you need to make sure the serial console is connected before
starting the system up, otherwise you'll end up missing the BIOS setup
menu and the system will either be in the 10 second delay (that allows
you to make a selection before it boots into the OS), or it 

Re: where is the image of openbsd arm ?

[bytevolcano]

On Fri, 24 Jun 2016 04:30:39 +0300
li...@wrant.com wrote:
> 
> What is more important is the level of engineering information
> available from the manufacturer (PC Engines) web site including tech
> specs, manual, BIOS updates, accessories, enclosures, diag boards and
> also: Schematics!

I certainly dig schematics! Don't forget, they use coreboot.

> 
> This seems to be by far more friendly to both engineer & consumer
> users.
> 
> PC Engines APU2 product line
> [http://www.pcengines.ch/apu2b2.htm]
> 
> 1) How do the APU systems go as pricing to comparable systems from
> other similar (industrial class, desktop enclosure) manufacturers?

I have two APU2C4 boards.

The price is not bad, and the ALIX/APU boards are not loaded with
consumer-grade "ooh, aah" bullet-point rubbish, unlike some of the VIA
boards which are (quite worryingly) also marketed towards medical
devices.

I am just a little disappointed in the way the components used are
just the consumer/low-end commercial grade versions (0-70degC operating
temps, etc). However, it certainly saves cost!

In addition, the clips for the mSATA/mPCIe slots, given that the use of
metallic screw points would improve grounding to the devices and would
be a lot more robust and resilient against vibration; with screw posts,
there is the option of using rubber washers too. And, screw posts would
cost an order of magnitude less, considering the cost of assembly too.

> 
> 2) How is the OpenBSD experience on the APU systems, do they have
> serial RS232 console (serial BIOS), do they expose all the hardware
> to OpenBSD?

The serial (RS232) console is set up to use 115200 baud by default (I
am unsure if this is changeable), so make sure this is
in /etc/boot.conf:

stty com0 115200
set tty com0

I would in fact recommend writing "installXX.fs" directly to a USB, and
then mounting /dev/sd#a to edit boot.conf to add those lines in right
at the top, before installing. It makes life easier.

I have not had the opportunity to test the GPIO support though; the
watchdog timer is not supported by OpenBSD, so whatever you do, do not
enable the watchdog timer yet.

> 
> Thank you for providing valuable technical feedback on these what
> appears to be the smarter choice over the other low power devices.
> 

It is definitely the smarter choice; on average, I notice around 5-6W
consumption, although that does vary depending on load.

The header pitches are 2.54mm too; this makes it very easy to obtain
plugs to connect to these headers.

Re: Is there such a thing as a fanless OpenBSD-capable laptop?

[bytevolcano]

I'll see what I can get for you, ropers. In the mean while, I can say
that most of the devices on my CF-30 and CF-31 function well, as
indicated by the dmesg. Then again, they only have basic options on
those laptops.

On Mon, 13 Jun 2016 09:25:29 +0200
ropers <rop...@gmail.com> wrote:
> 
> Also, while dmesg requests aren't a bad idea (bytevolcano? pretty plz?
> joekiser? when available?), ...

pledge(2) API ideas for libraries

[bytevolcano]

I have thought of a way pledge(2) can be made a little more
library-friendly.

This is not a patch, but just a thought.
There are 2 setups I have thought of:

=== 1. Variable arguments ===

int pledge(const char *promises, const char *paths[])
{
return vpledge(1, promises, paths);
}

int vpledge(const size_t npledge, ...);

-

In a program, this may be something like this:

#include 
#include 
#include 
#include 
#include 
#include 

int main(void) {
if(vpledge(5, "stdio rpath wpath cpath", NULL,
ultra_promises, ultra_pledgepaths,
extra_promises, NULL, super_promises, NULL,
mecha_promises, mecha_pledgepaths) == -1)
errx("pledge");

... [other code] ...
};


 ---

In vpledge(), "npledge" refers to the number of pledge-pairs, which
consist of:

const char *promises, const char *paths[]

These have the same semantics as the original pledge().

A library can export *_promises and *_pledgepaths symbols, pointing to
static text. This allows the library to change without the program
being affected because the new library changes call something outside
the original pledge() of a program.

= 2. Using a struct ==

-

struct pledge {
char *promises;
char *paths[];
};

-

int pledge(const char *promises, const char *paths[])
{
struct pledge pl = {
.promises, paths
};

return pledges(1, );
}

int pledges(const size_t npledge, const struct pledge pledge_array[]);

-

In a program, this may be something like this:

#include 
#include 
#include 
#include 
#include 
#include 

int main(void) {
struct pledge pl[4];

pl[0].promises = "stdio rpath wpath cpath";
ultra_getpledge([1]);
extra_getpledge([2]);
super_getpledge([3]);
mecha_getpledge([4]);

if(pledges(5, pl) == -1)
errx("pledge");

... [other code] ...


};


 ---


A library can tell the application what pledges are in use as follows:


static const char *pledge_promises = "stdio fattr sendfd recvfd"

void ultra_getpledge(struct pledge *const pl)
{
pl->promises = pledge_promises;
pl->paths = NULL;
}


==

I think that #1 has the advantage of it being easier to code so a
program can ratchet down its abilities. #2 allows one to group the
pledge arguments into a single struct.

Thoughts?

Re: Is there such a thing as a fanless OpenBSD-capable laptop?

[bytevolcano]

On Mon, 13 Jun 2016 05:25:17 +0300
li...@wrant.com wrote:

> ... until you meet the quality expectations.

Irony mode ACTIVATE.

Re: Is there such a thing as a fanless OpenBSD-capable laptop?

[bytevolcano]

If you can't read the question properly, please remain silent.

On Mon, 13 Jun 2016 02:21:48 +0300
li...@wrant.com wrote:

> For you only, the archives deserve much better: higher quality
> threads.
...
> You're in for a LOT of disappointment if you follow marketing material
> without dmesg and live field use reports.  This is the OpenBSD "misc@"
> mailing list, and it is expected people consult these archives for
> real useful correct quality information.  Or at least minimum
> attempts at it.
> 
> From a future visitor perspective this thread should be ignored.  It
> would not make a happy future OpenBSD developer, not even a BSD user.
> 
> This is mostly incomplete self oriented desktop companion media centre
> laptop incompetence all around.  Pretty lame.  Skip it, ask for dmesgs
> on actively usable for development or alternatively a "communications"
> devices from actual OpenBSD people, and not sales pitching affiliates.

Re: Is there such a thing as a fanless OpenBSD-capable laptop?

[bytevolcano]

Thanks for all the private personal attacks and abusive messages such
as this one, Wrant. Really appreciate it.

On Sun, 12 Jun 2016 13:46:47 +0300
li...@wrant.com wrote:

> Shithead.  Get lost.  You're on auto-delete.  You don't exist.

Re: Is there such a thing as a fanless OpenBSD-capable laptop?

[bytevolcano]

Allow me to explain that complex thought.

I didn't say that all machines are useless, nor did I say that any
machine is useless. One machine that is useful for Purpose #1 is
useless for Purpose #2; likewise, the machine that works well for
Purpose #2 is quite possibly useless for Purpose #1.

There may be a good replacement for a machine that can do Purpose #1,
but not one that can work for both #1 and #2.

What I was trying to say was that the term "desktop" in this context is
a very broad term; one person's idea of a desktop replacement is
going to be very different to another person's idea of a desktop
replacement.

On Sun, 12 Jun 2016 09:46:00 +0300
li...@wrant.com wrote:

> Sun, 12 Jun 2016 11:07:24 +1000 
> > On the other hand, those types of machines are useless for high-end
> > video editing, which may be what a "desktop" is to you.  
> 
> That's one very complex thought, hold it, keep still, don't move an
> inch. No machine is useless, it's the operator that makes use of it,
> go figure.

Re: Is there such a thing as a fanless OpenBSD-capable laptop?

[bytevolcano]

On Sun, 12 Jun 2016 03:21:40 +0300
li...@wrant.com wrote:

> Sat, 11 Jun 2016 20:03:37 +0200 ropers 
> > Does anybody here have a fanless laptop they run OpenBSD on?
> > (Possibly even as their primary computer? How poor of a desktop
> > replacement is it?)  
> 
> For a true no moving parts passive cooling system, you're out of luck
> with the desktop replacement idea.  Unless your desktop is running in
> the wireless network you connect to.  Basically, you're asking in the
> 10-20W form factor machine, which can function on convection with low
> CPU frequency even when it blocks due to failed maintenance: atom CPU.
> 

In a lot of ways though, that depends on what a "desktop" really is to
you. For instance, you can have a "desktop" in which all you do is
email, a bit of web browsing here and there, and office work. That
doesn't need much power, so those 10-20W machines are perfect for this.

On the other hand, those types of machines are useless for high-end
video editing, which may be what a "desktop" is to you.

Re: Is there such a thing as a fanless OpenBSD-capable laptop?

[bytevolcano]

I do have a Panasonic Toughbook CF-30 which doesn't have a fan, I have
successfully run -current on it.
If you want something more modern, but a bit smaller, the CF-19 may be
a good choice. It is a bit small though.

On Sat, 11 Jun 2016 20:03:37 +0200
ropers  wrote:

> Does anybody here have a fanless laptop they run OpenBSD on?
> (Possibly even as their primary computer? How poor of a desktop
> replacement is it?)
> 
> If not, is there anything that comes close (and how much can I not
> afford it)?

Re: hardware recommendation for openbsd-based thin client?

[bytevolcano]

Hello Marko,

Perhaps look into VIA's EPIA boards. They offer a pico-ITX
form factor (pretty close to the size of an audio cassette), with VGA
and keyboard. Whilst not all of the features (eg. watchdog) will work,
it should do for your purposes.

I have used a P900 board and it seems to work fine. I have used it
mostly as a headless system, but the console is displayed fine on the
VGA port. I haven't used much X11 on it though.

I am not sure I'd go with the newer (P910) board yet, as the VX11H
chipset doesn't appear to be supported by OpenBSD.

Or perhaps those Shuttle PCs, but I haven't tried them myself.
http://global.shuttle.com/main/productsDownload?productId=1585

On Thu, 26 May 2016 14:40:09 +0200
Marko Cupać  wrote:

> Hi,
>
> I need to implement a few dozen boxes whose only purpose will be
> connecting to RDP servers. I have figured out the software part -
> OpenBSD + slim + openbox + freerdp, but I haven't yet decided about
> the hardware part. It needs to be of amd64 architecture, and it needs
> to run OpenBSD. Local storage is not a concern, SD card would be
> enough. In fact, I'd go for diskless zero client if OpenBSD's
> implementation supported CIDR.
>
> Something like PCengines' APU, but in monitor+mouse+keyboard world.
>
> Any recommendations? Thank you in advance.
> --
> Before enlightenment - chop wood, draw water.
> After  enlightenment - chop wood, draw water.
>
> Marko Cupać
> https://www.mimar.rs/

Re: Suggestion: new webpage for openbsd.org

[bytevolcano]

On Fri, 20 May 2016 03:50:51 +0300
li...@wrant.com wrote:

> Interesting, the moment some other systems started swapping designs,
> the moment their public knew they've sold out and commercialised in.

This is a good point; I have certainly noticed this on a lot of other
sites and projects. As soon as they "upgrade" to "Web 2.0" (with all
the image-buttons-for-links, rounded corners, low-contrast text,
JavaScript galore, etc), it's easy to predict the fate of that project.

> > For instance, AsiaBSDCon is listed 12 times. Maybe it would be a
> > better layout to group by that event.  
> 
> No, historic list it is, these things happen over time.  You want
> reorder, do it local after retrieval, think before posting please.

To add to that, they *are* grouped by event. AsiaBSDCon 2015 is not the
same as AsiaBSDCon 2012, for example. And the list is in chronological
order anyway, which is probably the best order for this kind of list.

> 
> > As I said, I'm no web dev--just a user of it for a long time.  
> 
> Other users exist, and they go back many years in time with the
> system.
> 

And on that note, there are over 7 billion people on this planet. You
can't please everyone. Change the website, and people will complain.
Keep the website the way it was before, people will complain.

Re: Suggestion: new webpage for openbsd.org

[bytevolcano]

On Sun, 22 May 2016 09:32:47 +0200
Reinhold Straub  wrote:

> On 21.05.16 01:12, Theo de Raadt wrote:
> 
> > I think the site is fine.  Thanks for the table above.  I agree
> > there would be value in small tweaks to improve the view for narrow
> > displays.  
> 
> Wouldn't it suffice to replace
> 
>  alt="[OpenBSD 5.9]">
> 
> with
> 
>  style="max-height:199;max-width:599" alt="[OpenBSD 5.9]">

It doesn't seem like this change offers any merit whatsoever.
It could even be simplified:



Using XHTML 1.0 Strict wouldn't be a bad idea, since this is supported
on all modern browsers, and even Dillo and Lynx support it. At the
moment the page triggers the browsers' "quirks" modes.
Just some food for thought.

> 
> ?
> 
> And insert
> 
>  a {text-decoration:none} a:hover {text-decoration:underline} 
> 
> 
> to get a more pleasant appearance of the hyperlinks?
> 

Because that would confuse users; is conventional to have links as
underlined text all the time.

Re: Alternate Puffy Logo Design

[bytevolcano]

On Thu, 19 May 2016 15:18:45 -0400
"Ted Unangst"  wrote:

> Mihai Popescu wrote:
> > First, the webpage design change suggestion, then the logo
> > alternative ... I guess a project name change suggestion will
> > follow, I'm curious if this will be till weekend.  
> 
> We're changing version scheme instead. OpenBSD 6.0 will actually be
> OpenBSD 60.
> 

Everyone's different, and so different people require different features.
I suggest dividing OpenBSD into a few editions to give people a choice:

OpenBSD 600.0 Home Basic
OpenBSD 600.0 Home Premium
OpenBSD 600.0 Home Standard
OpenBSD 600.0 Home Essentials
OpenBSD 600.0 Home Professional
OpenBSD 600.0 Home Ultimate
OpenBSD 600.0 Professional Basic
OpenBSD 600.0 Professional Premium
OpenBSD 600.0 Professional Standard
OpenBSD 600.0 Professional Essentials
OpenBSD 600.0 Professional Professional
OpenBSD 600.0 Professional Ultimate
OpenBSD 600.0 Enterprise Edition
OpenBSD 600.0 Ultimate Basic
OpenBSD 600.0 Ultimate Premium
OpenBSD 600.0 Ultimate Standard
OpenBSD 600.0 Ultimate Essentials
OpenBSD 600.0 Ultimate Professional
OpenBSD 600.0 Ultimate Ultimate
...

Re: Is loss of read-only /usr permanent?

[bytevolcano]

li...@wrant.com wrote:
> Defending read only file systems on a writable medium is pointless, but
> your option, which does not qualify as a bug report.  Now read one book.

Wrant, calm down and curb the attitude please.
You often come up with good stuff here, and there are even things you have said 
in this thread which I agree with, but show this attitude the door.
Snide remarks and associated rudeness (eg. "Now read one book"), 
unsubstantiated blanket statements (eg. "X is pointless"), and baseless 
accusations (eg. while discussing UPS issues) do not add anything of value to 
this discussion.
This wasn't a bug report either. This was mainly asking for clarification about 
what's going on; that's what was given.

Just because people come up with reasoning that you don't agree with, doesn't 
automatically make it dumb or pointless.

Re: Suggestion: new webpage for openbsd.org

[bytevolcano]

I agree, we need buttons with rounded corners and ones that appear when
you hover your mouse over them. Those hyperlinks in the current OpenBSD
site are sharp and someone could poke their eyes out.

On Wed, 18 May 2016 11:00:54 +0530
Jay Patel  wrote:

> I would like to see openbsd.org in http://openbsdfoundation.org/ this
> style
>
> On Tue, May 17, 2016 at 12:41 PM, Joakim Frostegård <
> joakim.frosteg...@gmail.com> wrote:
>
> > Hi,
> >
> > I’ve made a responsive new webpage replacement for the
> > in my opinion somewhat aged openbsd.org .
> >
> > It’s available at
> > http://greatest-ape.github.io/openbsd-site/public_html/
> >  with the
> > repo at https://github.com/greatest-ape/openbsd-site
> >  .
> >
> > The idea is to replace index.html but for all other pages just
> > replace the stylesheets. In so far, I’ve included a few other
> > pages, including plat.html, goals.html and alpha.html.
> >
> > I’ve tried to keep the page without bells and whistles, that is:
> > * Just static HTML and CSS
> > * No frameworks
> > * No javascript
> > * Minimalist design
> >
> > though I have included the Apache 2-licensed Open Sans
> > from Google Fonts. If you like the page, I guess we could
> > build our own font instead of using the google repository.
> >
> > Is this the right place to post this? Are you (the openbsd devs)
> > interested in this at all?
> >
> > If yes, we would also need to make sure that the creator of
> > the nice openbsd logo included is happy with us using it for
> > the webpage. Apart from that, I would be happy to license
> > my work under BSD, MIT or whatever you want.
> >
> > Cheers
> > Joakim

Re: Suggestion: new webpage for openbsd.org

[bytevolcano]

The reason the OpenBSD site hasn't changed for years, aka. "aged", is
because there is no need to change just for change's sake.
A lot of problems in this world are caused by the young generation
being taught to "ALWAYS IMPLEMENT CHANGE!" by new-agey college
professors and teachers.

In fact, learning from experience seems to be a mortal sin these days
with technology.

I am not looking forward to the future at all; next up, let's demolish
the Colosseum and build it with modern materials and technology. While
we're at it, we may as well do the same with the Leaning Tower of Pisa.

The OpenBSD site in its current form seems to serve the content in a
well-structured, well-organised manner.

So, as vintage as the OpenBSD site may be, if it ain't broke, don't
fix it. ;)


On Tue, 17 May 2016 09:11:44 +0200
Joakim Frostegård  wrote:

> Hi,
>
> I’ve made a responsive new webpage replacement for the
> in my opinion somewhat aged openbsd.org .
>
> It’s available at
> http://greatest-ape.github.io/openbsd-site/public_html/
>  with the
> repo at https://github.com/greatest-ape/openbsd-site
>  .
>
> The idea is to replace index.html but for all other pages just
> replace the stylesheets. In so far, I’ve included a few other
> pages, including plat.html, goals.html and alpha.html.
>
> I’ve tried to keep the page without bells and whistles, that is:
> * Just static HTML and CSS
> * No frameworks
> * No javascript
> * Minimalist design
>
> though I have included the Apache 2-licensed Open Sans
> from Google Fonts. If you like the page, I guess we could
> build our own font instead of using the google repository.
>
> Is this the right place to post this? Are you (the openbsd devs)
> interested in this at all?
>
> If yes, we would also need to make sure that the creator of
> the nice openbsd logo included is happy with us using it for
> the webpage. Apart from that, I would be happy to license
> my work under BSD, MIT or whatever you want.
>
> Cheers
> Joakim

Re:

[bytevolcano]

On Mon, 16 May 2016 10:47:02 +
1 9  wrote:

> What editor? vim or emacs? what is the reason?

MS-DOS EDLIN.

Re: mfs vs tmpfs: advantages and disadvantages

[bytevolcano]

On Tue, 03 May 2016 02:53:36 -0600
Theo de Raadt  wrote:

> mfs is reliable.

> tmpfs has bugs, and as a result of those bugs, it has fewer and fewer
> users.

> Or, maybe there are fewer problem reports because fewer people use
> it, because those who tried to use it ran into problems and walked
> away from it?

Thanks Theo, that explains a lot. The future doesn't look too good for
tmpfs in this case.

> Absolutely no way, that makes no sense.

Understood; I wasn't going to write anything until I was sure anyway.

Re: mfs vs tmpfs: advantages and disadvantages

[bytevolcano]

I actually wrote a patch to that a while back, and it was not accepted.
Looking back, I am not disappointed that it was rejected, and it forced
me to find another solution: shell scripts, included below.

However, in light of what Theo said, I'm possibly going to move back to
mfs; even if I haven't had any issues with tmpfs yet, I feel
the need to be somewhat proactive.

Whilst not exactly Michelangelo's finest work of art, it's probably
better than the original set of patches I submitted.


I use the following in /etc/fstab:

swap /var/log tmpfs.sh rw,nodev,noexec,nosuid,-s=64M,-P=/M/var/log


Stored in /sbin/mount_tmpfs.sh:

#!/bin/sh

while getopts :g:m:n:o:P:s:u: OPT; do
if [ "$OPT" == 'P' ]; then
TEMPLATE=$OPTARG
else
MCPARAM="$MCPARAM -$OPT $OPTARG"
fi
done
shift `expr $OPTIND - 1`

/sbin/mount_tmpfs $MCPARAM $*

if [ "$TEMPLATE" != "" ]; then
shift `expr $# - 1`
(cd "$TEMPLATE"; /bin/pax -rw -pe . "$1")
fi
 


On Tue, 3 May 2016 04:57:54 -0400
Jiri B  wrote:

> On Tue, May 03, 2016 at 05:08:06PM +1000, bytevolc...@safe-mail.net
> wrote:
> > With tmpfs being in the tree for the last 2+ years (since OpenBSD
> > 5.5), I would like to ask, besides the "-P" option in mount_mfs,
> > what is the advantage of using mfs over tmpfs?  
> 
> tmpfs on Bitrig does support snapshots, which can be used as an
> alternative to mpf's "-P". If you are interested check it out.
> 
> j.

mfs vs tmpfs: advantages and disadvantages

[bytevolcano]

Hello,

With tmpfs being in the tree for the last 2+ years (since OpenBSD 5.5),
I would like to ask, besides the "-P" option in mount_mfs, what is the
advantage of using mfs over tmpfs?

It seems tmpfs has the following advantages:

 - Can grow or shrink; shrinks when files are erased.
 - Can impose definite limits on number of inodes/files (then again,
   this happens in mfs too).
 - Dedicated memory structures used, rather than just plonking an
   entire disk FS onto it.

I have seen discussions here:
http://marc.info/?l=openbsd-tech=139935771507987=2

There is a claim that tmpfs is not as stable on that thread, but that
was back in 2014 when this was still new.

I am willing to write a patch (or series of patches) to remove mfs
support if it is deemed to be unused/unnecessary; unfortunately I only
have access to an old amd64 machine for testing.

Thoughts?

Re: bioctl disk encryption

[bytevolcano]

On Sat, 9 Apr 2016 20:18:11 -0400
Matt Schwartz  wrote:

> I really like the bioctl full disk encryption feature. I would love
> to see it extended to support multiple users/passkeys. I once worked
> with a commercial full disk encryption product that allowed this ...

You could store keying material on those iStorage datAshur sticks; they
support a user and admin key. Just have one for each user.

Alternatively, you could just store the keying material on the same
disk, but on encrypted softraid partitions, each encrypted with its own
key. Assuming there is already one softraid partition 'a' on the disk,
you have support for 14 different users: an admin with the primary key
material stored on his own USB drive, and 'd', 'e', 'f', 'g', 'h', 'i',
'j', 'k', 'l', 'm', 'n', 'o', and 'p' to encrypt with softraid, storing
another RAID chunk which stores the key material. And you may even be
able to use 'b' but as I understand, this is reserved for swap space.

Not ideal, but "extended to support multiple users/passkeys" seems
incredibly complex. Perhaps an example scenario for such usage would
help.

As someone else pointed out, access to the encrypted partition
basically requires root access to the system anyway.

> and could even be managed over a network.

So basically, an exploit waiting to happen. 

> Coming up with a solution to manage encryption keys over a network is
> trivial ...

Well go on then. Where's the code?

> but I'd love to see the full disk encryption extended to support
> multiple users with individual passkeys.

Right. Any ideas on how to implement this?

Re: date not respect for 5.8 and 5.9

[bytevolcano]

Like, because OpenBSD is for, like, REBELS, mn! Which is like,
totally gnarly dude!

On Thu, 31 Mar 2016 10:58:00 +0200
"Max Power"  wrote:

> Hi guys!
> Why the release 5.8 and 5.9 did not comply with the canonical date
> of the 1th November and of the 1th May?
> 
> Thanks in advance for your reply.

Re: Booting Live openbsd image on fat32 media

[bytevolcano]

The Windows DISKPART command-line utility (Windows Vista and later) can
split your USB disk into multiple partitions.

There are no GUI tools that can do this, to the best of my knowledge,
though perhaps the Disk Management (diskmgmt.msc) snap-in can.

On Mon, 21 Sep 2015 16:24:40 +0330
Mohammad BadieZadegan  wrote:

> OK, It's true,
> But spliting the memstick into 2 partition causes more questions:
> 1.What tools can do that best?
> 2.What is the size of partitions?
> 3.How can write OpenBSD memstick image on the last partition?
> 
> On Mon, Sep 21, 2015 at 4:12 PM, Dmitrij D. Czarkoff
>  wrote:
> 
> > Mohammad BadieZadegan said:
> > > How put OpenBSD image on it that don't curropt its file system or
> > > booting OpenBSD?
> >
> > The easiest way is to split your drive in two partitions: first one
> > should be FAT32 if you want it so, and the last one should be
> > OpenBSD slice.
> >
> > Windows and most consumer devices' firmwares don't read partition
> > table on USB flash devices, so these systems won't notice your
> > OpenBSD partition, but it will be bootable.
> >
> > --
> > Dmitrij D. Czarkoff

Re: Correction to the AnonCVS documentation

[bytevolcano]

Please ignore/delete this.

The SMTP server I was using was initially blocked, and thanks to the
list owner, it is now fixed. As a result, this message may have been
backlocked and sent.

It is essentially a duplicate of another message, which has received
reasonable replies.

On Mon, 8 Jun 2015 04:04:57 +1000
bytevolc...@safe-mail.net wrote:

 Hello all,
 
 I noticed on http://www.openbsd.org/faq/faq5.html#BldGetSrc that
 there is information about preloading the tree, but does not mention
 that getting to -current requires -rHEAD at least the first time using
 'cvs update' after pre-loading the tree with the source files from the
 last release.
 
 I discovered (the semi-hard way) that to get to -current, you need
 -rHEAD to be specified in the command line. This is after
 pre-loading the tree, because the (src/sys/xenocara).tar.gz files all
 have a check out of OPENBSD_5_7 (or whatever -stable release), frozen
 to that point at the time of releasing. Running cvs up simply gets
 me to the latest -stable.
 
 My .cvsrc (between the hyphen lines):
 
 ---
 # $OpenBSD: dot.cvsrc,v 1.1 2013/04/01 16:55:26 espie Exp $
 #
 cvs -q -danon...@anoncvs.au.openbsd.org:/cvs
 diff -up
 update -Pd
 checkout -P
 ---
 
 It seems the (src/sys/xenocara).tar.gz files are not
 in the snapshots directory of any of the FTP mirrors I've seen.
 
 I am willing to write a patch for this, but I want to ensure:
 
 1. I am not missing anything hidden somewhere in another FAQ.
 2. There are no mirrors which have the (src/sys/xenocara).tar.gz files
 in their /pub/OpenBSD/snapshots directory.
 3. That there is no other CVS command magic that I have missed, that
 may have been covered by the FAQ.
 4. That there are no other reasons not to document this information.
 
 I will appreciate input from users and devs alike.

Correction to the AnonCVS documentation

[bytevolcano]

Hello all,

I noticed on http://www.openbsd.org/faq/faq5.html#BldGetSrc that
there is information about preloading the tree, but does not mention
that getting to -current requires -rHEAD at least the first time using
'cvs update' after pre-loading the tree with the source files from the
last release.

I discovered (the semi-hard way) that to get to -current, you need
-rHEAD to be specified in the command line. This is after
pre-loading the tree, because the (src/sys/xenocara).tar.gz files all
have a check out of OPENBSD_5_7 (or whatever -stable release), frozen
to that point at the time of releasing. Running cvs up simply gets me
to the latest -stable.

My .cvsrc (between the hyphen lines):

---
# $OpenBSD: dot.cvsrc,v 1.1 2013/04/01 16:55:26 espie Exp $
#
cvs -q -danon...@anoncvs.au.openbsd.org:/cvs
diff -up
update -Pd
checkout -P
---

It seems the (src/sys/xenocara).tar.gz files are not
in the snapshots directory of any of the FTP mirrors I've seen.

I am willing to write a patch for this, but I want to ensure:

1. I am not missing anything hidden somewhere in another FAQ.
2. There are no mirrors which have the (src/sys/xenocara).tar.gz files
in their /pub/OpenBSD/snapshots directory.
3. That there is no other CVS command magic that I have missed, that
may have been covered by the FAQ.
4. That there are no other reasons not to document this information.

I will appreciate input from users and devs alike.