Re: pflogd write /var/run/mypflogdinstance.pid?

2020-12-13 Thread Consus

On Sun, Dec 13, 2020 at 10:42:20PM +0300, Consus wrote:

On Sun, Dec 13, 2020 at 08:27:24PM +0100, Harald Dunkel wrote:

At least OpenBSD is not alone with this problem. On Debian there
is a tool "/bin/pidof", trying to guess the pid of a daemon to kill
by looking at the process list as well.


Some dude from Google came up with a good solution (for Linux of
course). If you open a /proc/[pid] directory this PID cannot be recycled
unless you close the fd. Hence you can do this:

1. Read /var/run/foobard.lock and get PID
2. Open /proc/[pid]
3. Check that PID is in fact belongs to an instance of foobard
4. kill() it

Easy.


Hmm... My memory served me bad. It's not that PID won't by recycled,
it's that fd referencing it (you can get one from opening /proc/[pid])
will becomes invalid after PID is dead/recycled. So calling
pidfd_send_signal(fd, ...) will fail instead of killing the wrong
process.



Re: pflogd write /var/run/mypflogdinstance.pid?

2020-12-13 Thread Consus

On Sun, Dec 13, 2020 at 08:27:24PM +0100, Harald Dunkel wrote:

At least OpenBSD is not alone with this problem. On Debian there
is a tool "/bin/pidof", trying to guess the pid of a daemon to kill
by looking at the process list as well.


Some dude from Google came up with a good solution (for Linux of
course). If you open a /proc/[pid] directory this PID cannot be recycled
unless you close the fd. Hence you can do this:

1. Read /var/run/foobard.lock and get PID
2. Open /proc/[pid]
3. Check that PID is in fact belongs to an instance of foobard
4. kill() it

Easy.



Re: OpenBSD insecurity rumors from isopenbsdsecu.re

2020-05-12 Thread Consus
On Tue, May 12, 2020 at 10:47:48AM +0200, i...@aulix.com wrote:
> Sure I do not have such skills, I am a very noob trying to build a
> secure console and router, but most likely IMHO the backdoors are
> targeted to be used from invisible virtualization trojans on X86? I
> was even suggested to avoid Libreboot on X86 because it is GNU, though
> for me it is sometimes difficult to understand where trolling is in
> this area of my interest.
> 
> Is not systemd one of such backdoors? Does it include any interesting
> "features"  except so called "init system"?

Also NSA controls your brain with 5G radio waves. Go burn some towers in
the name of the Freedom!



Re: OpenBSD insecurity rumors from isopenbsdsecu.re

2020-05-07 Thread Consus
On Thu, May 07, 2020 at 04:00:15PM +0200, i...@aulix.com wrote:
> Dear OpenBSD fans,
> 
> Can you please comment negative appraisal from the following website:
> 
> https://isopenbsdsecu.re/quotes/
> 
> I did not want to hurt anyone, just looking for a secure OS and
> OpenBSD looked very nice to me before I have found this website.

The fun thing to do: offer $50k rewards for code execution
vulnerabilities and wait for results.



Re: The 16 partitions thread

2020-04-30 Thread Consus
On Thu, Apr 30, 2020 at 07:22:35AM -0500, Ed Ahlsen-Girard wrote:
> Some people read replies in misc and say, "wow, Theo and the OBSD devs
> are obnoxiously harsh.'
> 
> I read the 16 partitions thread and think, "I marvel at their patience
> with interlocutors who have not read the relevant source code and give
> no indication that they would understand it if they did."

Yeah, stupid users, right? Who needs them anyways.



Re: Sound is good on OpenBSD

2020-04-28 Thread Consus
On Tue, Apr 28, 2020 at 03:01:15PM +0300, Yury Grebenkin wrote:
> OpenBSD gives a better sound experience on my machine than several
> Linux distributions I have used and FreeBSD. Just want to say thank
> you to all the people involved and state the fact that OpenBSD does
> make a difference.

Blood virgin sacrifice tends to make FLAC even better.



Re: GNU+Linux corporate takeover, was: Wine for OpenBSD?

2020-04-14 Thread Consus
On Tue, Apr 14, 2020 at 04:15:20PM -0400, Daniel Jakots wrote:
> On Tue, 14 Apr 2020 16:05:56 -0400, Raul Miller 
> wrote:
> 
> > Got any good docs on how to debug (or monitor) D-Bus issues?
> 
> You're asking help to debug D-Bus on an OpenBSD mailing list? Why don't
> you bring this sooo interesting discussion off-list?

OpenBSD has D-Bus too, nah?



Re: GNU+Linux corporate takeover, was: Wine for OpenBSD?

2020-04-14 Thread Consus
On Tue, Apr 14, 2020 at 04:05:56PM -0400, Raul Miller wrote:
> On Tue, Apr 14, 2020 at 3:38 PM Consus  wrote:
> > It is modular to a degree, but separating services requires a bit of
> > work so yeah, in this area systemd sucks. Documentation is pretty good
> > though.  I don't like the complexity of the thing, but I've never been
> > stuck because there is not enough docs.
> 
> Got any good docs on how to debug (or monitor) D-Bus issues?

Sure, try busctl(1).



Re: GNU+Linux corporate takeover, was: Wine for OpenBSD?

2020-04-14 Thread Consus
On Tue, Apr 14, 2020 at 03:12:18PM -0400, Raul Miller wrote:
> On Tue, Apr 14, 2020 at 1:37 PM Consus  wrote:
> > On Tue, Apr 14, 2020 at 05:10:14PM +0200, Oddmund G. wrote:
> > > I know all this, Ottavio. I have been using GNU+Linux since 1994 after
> > > several years with Ultrix/VMS/OpenVMS @DEC: Slackware in the beginning, 
> > > then
> > > Debian until the forced introduction of systemd and the rest of the crap
> > > being considered as 'much better' and 'mandatory'.
> >
> > Because systemd is good enough "base tools suite". Think of it as a base
> > system like OpenBSD provides. It has a _lot_ of issues with reliability,
> > consistency and whatever, but simply put, other Linux folks failed to
> > provide similar tools. Maybe someday someone will make something better.
> 
> I think that thinking of it this way would be some kind of mistake:
> 
> Last I checked, systemd was not modular, was poorly documented,
> exhibited incompatibilities with basically all historical interfaces,
> and had introduced a variety of boot-time race conditions (which
> mostly hit people who tried to change the configuration from the
> default). These are all solvable problems, but OpenBSD is not the only
> distribution which suffers from a lack of competent contributions.

It is modular to a degree, but separating services requires a bit of
work so yeah, in this area systemd sucks. Documentation is pretty good
though.  I don't like the complexity of the thing, but I've never been
stuck because there is not enough docs.

Can't say much about historical interfaces.

> I don't think Linux is particularly doomed -- computer systems tend to
> stick around far longer than most sales pitches would have you
> believe. But these are concerning issues.

Systemd actually solved a bunch of problems so I don't think it's bad or
makes Linux "doomed".

> But that's also why these sorts of discussions tend to be fairly
> worthless.

Of course they are. Just a chit-chat.



Re: GNU+Linux corporate takeover, was: Wine for OpenBSD?

2020-04-14 Thread Consus
On Tue, Apr 14, 2020 at 05:10:14PM +0200, Oddmund G. wrote:
> I know all this, Ottavio. I have been using GNU+Linux since 1994 after
> several years with Ultrix/VMS/OpenVMS @DEC: Slackware in the beginning, then
> Debian until the forced introduction of systemd and the rest of the crap
> being considered as 'much better' and 'mandatory'.

Because systemd is good enough "base tools suite". Think of it as a base
system like OpenBSD provides. It has a _lot_ of issues with reliability,
consistency and whatever, but simply put, other Linux folks failed to
provide similar tools. Maybe someday someone will make something better.



Re: openbsd.org down?

2020-04-13 Thread Consus
On Mon, Apr 13, 2020 at 04:53:22PM +0300, Gökşin Akdeniz wrote:
> On the other hand, DNS works.

Maybe it's related to the network?

$ ping -c 5 openbsd.org
PING openbsd.org (129.128.5.194) 56(84) bytes of data.
>From obsd3.srv.ualberta.ca (129.128.5.194) icmp_seq=1 Destination Port 
>Unreachable
>From obsd3.srv.ualberta.ca (129.128.5.194) icmp_seq=2 Destination Port 
>Unreachable
>From obsd3.srv.ualberta.ca (129.128.5.194) icmp_seq=3 Destination Port 
>Unreachable
>From obsd3.srv.ualberta.ca (129.128.5.194) icmp_seq=4 Destination Port 
>Unreachable
>From obsd3.srv.ualberta.ca (129.128.5.194) icmp_seq=5 Destination Port 
>Unreachable

--- openbsd.org ping statistics ---
5 packets transmitted, 0 received, +5 errors, 100% packet loss, time 9ms

$ ping -c 5 ftp.openbsd.org
PING ftp.openbsd.org (129.128.5.191) 56(84) bytes of data.
>From openbsd.sunsite.ualberta.ca (129.128.5.191) icmp_seq=1 Destination Port 
>Unreachable
>From openbsd.sunsite.ualberta.ca (129.128.5.191) icmp_seq=2 Destination Port 
>Unreachable
>From openbsd.sunsite.ualberta.ca (129.128.5.191) icmp_seq=3 Destination Port 
>Unreachable
>From openbsd.sunsite.ualberta.ca (129.128.5.191) icmp_seq=4 Destination Port 
>Unreachable
>From openbsd.sunsite.ualberta.ca (129.128.5.191) icmp_seq=5 Destination Port 
>Unreachable

--- ftp.openbsd.org ping statistics ---
5 packets transmitted, 0 received, +5 errors, 100% packet loss, time 9ms

$ ping -c 5 cvs.openbsd.org
PING cvs.openbsd.org (199.185.137.3) 56(84) bytes of data.
64 bytes from cvs.openbsd.org (199.185.137.3): icmp_seq=1 ttl=242 time=156 ms
64 bytes from cvs.openbsd.org (199.185.137.3): icmp_seq=2 ttl=242 time=154 ms
64 bytes from cvs.openbsd.org (199.185.137.3): icmp_seq=3 ttl=242 time=155 ms
64 bytes from cvs.openbsd.org (199.185.137.3): icmp_seq=4 ttl=242 time=154 ms
64 bytes from cvs.openbsd.org (199.185.137.3): icmp_seq=5 ttl=242 time=154 ms

--- cvs.openbsd.org ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 10ms
rtt min/avg/max/mdev = 154.154/154.627/155.517/0.637 ms



Re: Awaiting a diff [was: Re: File systems...]

2020-01-10 Thread Consus
On 11:28 Fri 10 Jan, Stefan Sperling wrote:
> On Fri, Jan 10, 2020 at 12:52:44PM +0300, Consus wrote:
> > On 20:06 Thu 09 Jan, Marc Espie wrote:
> > > It's been that way for ages. But no-one volunteered
> > > to work on this.
> > 
> > Anyone even knows about this? Aside from OpenBSD developers (who have
> > their plates full already) how an average person can find out that there
> > is rusty piece of code that should be taken care of?
> 
> Don't start looking at other people's problems before you can help yourself.
> Rewriting automounter for Theo as a first contribution is not likely to work.
> Find something small that annoys *you* and get involved by fixing that first.
> Learn how to approach and debug issues that affect you directly.
> 
> How did I get into OpenBSD wifi?
> Because my OpenBSD access point stopped accepting new associations after
> one about week of usage. It turned out this was one of those problems
> which had been known for years and all this time people had been switching
> to non-OpenBSD APs to work around it. I had lived with the problem for
> about a year or two, resetting the wifi interface on the AP whenever it
> happened.
> 
> Then I noticed that 'ifconfig ath0 scan' showed a very long list of known
> MAC addresses whenever the problem occurred. So I looked for a way trigger
> the problem faster than in one week and succeeded by running this loop
> on the client which made the problem appear after a few minutes:
> 
>   ifconfig iwn0 up
>   while sleep 5; do ifconfig iwn0 lladdr random; done
> 
> Looking at the code I found that known MACs never expired! Once the AP had
> reached its limit of learned MACs it accepted no new associations because
> no room was made for new MAC addresses. Fix was a 3-line diff, which I
> could verify with my above test.

Neat. Though I'm using OpenBSD only for a router and since issues
preventing me from using it on a desktop (or NAS) are pretty huge to be
my "good first issues" that's not an option, sadly. So only donations /
occasional bug reports from me :D



Re: Awaiting a diff [was: Re: File systems...]

2020-01-10 Thread Consus
On 11:08 Fri 10 Jan, Janne Johansson wrote:
> By using the parts that OpenBSD is made up of, and not automatically moving
> to other OSes as soon as you leave the comfort zone.

I'm not sure, but it seems like from a user perspective there is nothing
wrong with amd(8). Only that it keeps using legacy code.



Re: Awaiting a diff [was: Re: File systems...]

2020-01-10 Thread Consus
On 20:06 Thu 09 Jan, Marc Espie wrote:
> It's been that way for ages. But no-one volunteered
> to work on this.

Anyone even knows about this? Aside from OpenBSD developers (who have
their plates full already) how an average person can find out that there
is rusty piece of code that should be taken care of?



Re: OpenBSD's extremely poor network/disk performance?

2020-01-09 Thread Consus
On 17:22 Thu 09 Jan, Hamd wrote:
> Joe, are you a joke? Please stop insulting me, this is not
> my/your_personal_fancy_forum.
> 
> This will be my last post here in misc.
> 
> Default setups, no config. changes.
> Just patches installed.
> Same hardware.
> 
> FreeBSD:
> freebsd@test:~ # time sh -c "dd if=/dev/zero of=test.tmp bs=4k count=5
> && sync"
> 5+0 records in
> 5+0 records out
> 20480 bytes transferred in 0.239590 secs (854792500 bytes/sec)
> 0.000u 0.195s 0:00.25 76.0% 22+198k 0+1568io 0pf+0w
> 
> Result: *854.79 MB/s disk speed*
> 
> freebsd@test:~ # uname -a
> FreeBSD test.local 12.1-RELEASE-p1 FreeBSD 12.1-RELEASE-p1 GENERIC  amd64
> 
> OpenBSD:
> test$ time sh -c "dd if=/dev/zero of=test.tmp bs=4k count=5 && sync"
> 5+0 records in
> 5+0 records out
> 20480 bytes transferred in 12.303 secs (16645247 bytes/sec)
> 0m12.32s real 0m00.13s user 0m01.28s system
> 
> Result: *16.64 MB/s disk speed*
> 
> test$ uname -a
> OpenBSD test.local 6.6 GENERIC#3 amd64
> 
> You all guys, please don't get me wrong in any way, I truly adore
> cleanness, stability and security of OpenBSD, huge efforts of all the dev
> team is really, much appreciated!
> 
> I agree when it comes to OpenBSD, of course, security comes FIRST. But in
> 2020, a speed of 16 megabytes per second...hurts the users. A lot.
> 
> I really wish I could do contribute the code somehow..*sighs
> 
> Regards.

Please, stop using dd as a benchmark. Use fio or similar programs.



Re: Awaiting a diff [was: Re: File systems...]

2020-01-09 Thread Consus
On 10:45 Thu 09 Jan, Stefan Sperling wrote:
> On Thu, Jan 09, 2020 at 11:02:17AM +0300, Consus wrote:
> > On 18:15 Wed 08 Jan, Xiyue Deng wrote:
> > > It would be better to point out where to start, what hard problems to
> > > solve, what work has been done in this area that people can continue
> > > to work on.
> > 
> > They don't remember as there is no bugtracker.
> 
> When people report actual bugs, they get fixed so fast that tracking
> them over days or weeks would be pointless.
> 
> """
> We thank Theo de Raadt and the OpenBSD developers for their incredibly
> quick response: they published patches for these vulnerabilities less
> than 40 hours after our initial contact. 
> """ -- Qualys
> 
> Any non-critical stuff which gets reported ("my printer/wifi/usb doesn't 
> work",
> "kernel does not boot on my new laptop", "my system works but is slow") just
> lands in an endless pile of problems that someone might eventually decide to
> work on if they run into it again. Such issues happen over and over again,
> all the time. Any developer picking them up ASAP over and over would burn out,
> just like they do in companies with issue-tracker driven workflows. That's why
> people demanding loudly to get such issues fixed are told to shut up.
> 
> And keep in mind that at any given moment there are only about 50 to 100
> people doing actual work here. The rest of the world is busy elsewhere or
> slacking.

Relax, it was a joke.



Re: Awaiting a diff [was: Re: File systems...]

2020-01-09 Thread Consus
On 18:15 Wed 08 Jan, Xiyue Deng wrote:
> It would be better to point out where to start, what hard problems to
> solve, what work has been done in this area that people can continue
> to work on.

They don't remember as there is no bugtracker.



Re: sysupgrade to 6.6 failed at comp66.tgz

2019-11-24 Thread Consus
On 23:21 Sat 23 Nov, cho...@jtan.com wrote:
> > You can't seriously be calling "-x* -game*" an unsupported configuration ?  
> > Seems to me
> >  like a sensible thing to do on any box that's going to be headless for its 
> > entire life
> >  and only ever accessed via SSH (or text console at a push).
> 
> Lines 159-160 of /usr/sbin/sysupgrade read as follows:
> 
>   SETS=$(sed -n -e 's/^SHA256 (\(.*\)) .*/\1/' \
>   -e '/^INSTALL\./p;/^bsd/p;/\.tgz$/p' SHA256)
> 
> This is followed by ~45 lines which download, verify and extract
> them. The entire thing from that point takes up less than two
> thirds of this small laptop screen.
> 
> It would have been quicker to write a patch to include the desired
> functionality than create this email thread.
> 
> Here's a quick-and-dirty thing I just made up:
> 
> ed /usr/sbin/sysupgrade
> /^SETS=/s//: ${SETS:=/
> +s/$/}/
> wq
> 
> Now you can, possibly, set SETS in the environent to override what
> sysupgrade will even consider.

U - usability :D

I guess Theo is right and it's best to merge all sets into baseXX.tgz
(except for siteXX.tgz) to prevent "it works until it's not" situations.



Re: Starting redis fails with 'Bus error (core dumped)'

2019-11-17 Thread Consus
On 22:05 Sun 17 Nov, Unicorn wrote:
> On Sun, 2019-11-17 at 23:22 +0300, Consus wrote:
> > On 16:25 Sun 17 Nov, Unicorn wrote:
> > > After installing redis (and rspamd), before having modified any
> > > part of
> > > redis, starting redis with 'rcctl start redis' fails. I then tried
> > > running the binary itself in /usr/local/sbin/redis-server, which
> > > only
> > > returns 'Bus error (core dumped)'.
> > > 
> > > I changed the log level in the '/etc/redis/redis.conf' to debug,
> > > but do
> > > not get any more information about the reason for failure. Running
> > > 'grep -R redis /var/log/' did not give me any information either,
> > > and
> > > after changing the log level to debug, the only thing that changed
> > > is
> > > an unreadable 'redis-server.core' file appearing in '/var/log'.
> > 
> > Please, post the output of
> > 
> > # gdb /usr/local/sbin/redis-server /var/log/redis-server.core
> > 
> 
> Output:
> 
> GNU gdb 6.3
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and
> you are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for
> details.
> This GDB was configured as "arm-unknown-openbsd6.6"...(no debugging
> symbols found)
> 
> Core was generated by `redis-server'.
> Program terminated with signal 10, Bus error.
> (no debugging symbols found)
> Loaded symbols for /usr/local/sbin/redis-server
> Reading symbols from /usr/lib/libm.so.10.1...done.
> Loaded symbols for /usr/lib/libm.so.10.1
> Reading symbols from /usr/lib/libpthread.so.26.1...done.
> Loaded symbols for /usr/lib/libpthread.so.26.1
> Reading symbols from /usr/local/lib/liblua5.1.so.5.1...done.
> Loaded symbols for /usr/local/lib/liblua5.1.so.5.1
> Reading symbols from /usr/lib/libc.so.95.1...done.
> Loaded symbols for /usr/lib/libc.so.95.1
> Reading symbols from /usr/libexec/ld.so...Error while reading shared
> library symbols:
> Dwarf Error: wrong version in compilation unit header (is 4, should be
> 2) [in module /usr/libexec/ld.so]
> #0  0x133f3834 in SHA1Final () from /usr/local/sbin/redis-server
> (gdb) 

Damn it, on Linux it prints backtrace by default. Type `bt' in the gdb
prompt and post the output.



Re: Starting redis fails with 'Bus error (core dumped)'

2019-11-17 Thread Consus
On 16:25 Sun 17 Nov, Unicorn wrote:
> Hello again,
> 
> I am currently setting up redis with rspamd for my mail setup, but I am
> encountering an issue when trying to just start redis.
> For the record, I am following the guide at 
> https://poolp.org/posts/2019-09-14/setting-up-a-mail-server-with-opensmtpd-dovecot-and-rspamd/
> 
> After installing redis (and rspamd), before having modified any part of
> redis, starting redis with 'rcctl start redis' fails. I then tried
> running the binary itself in /usr/local/sbin/redis-server, which only
> returns 'Bus error (core dumped)'.
> 
> I changed the log level in the '/etc/redis/redis.conf' to debug, but do
> not get any more information about the reason for failure. Running
> 'grep -R redis /var/log/' did not give me any information either, and
> after changing the log level to debug, the only thing that changed is
> an unreadable 'redis-server.core' file appearing in '/var/log'.
> 
> I'd very much appreciate your help, thanks in advance!

Please, post the output of

# gdb /usr/local/sbin/redis-server /var/log/redis-server.core



Re: new rust-libtls crates

2019-11-05 Thread Consus
On 17:33 Sat 02 Nov, Reyk Floeter wrote:
> Why libtls?  Because it is a sane TLS API with secure defaults.  I
> trust the decisions of the LibreSSL developers and libtls provides
> some the best defaults.
> 
> The code works on OpenBSD and Linux.  Many distributions such as
> Ubuntu don't seem to provide LibreSSL packages, so the very nice
> libtls API is not available for them.  My crate tries to download,
> build, and link LibreSSL statically if it is not found. 

A bit of an offtopic, but most of the time people revert back to OpenSSL
due to lags in API compatibility between the two projects. Maybe it
would be better to provide libtls as a standalone library that can
coexist with OpenSSL.

E.g. install libssl.so and libcrypto.so as libressl.so and
librecrypto.so and make libtls.so depend on them instead of libssl.so
and libcrypto.so.



Re: OpenBSD 6.6 amd64 iavf(4) iavf / SR-iov 40G NIC lots of Jitter

2019-10-21 Thread Consus
On 13:33 Sun 20 Oct, Joseph Mayer wrote:
> Tom, is not the jitter you are experiencing totally normal overhead
> for a hypervisor.

Are you sure? E.g. VM (centos) on busy as hell Proxmox instance:

# ping -c 5 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=47 time=4.96 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=47 time=5.42 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=47 time=6.90 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=47 time=5.29 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=47 time=7.37 ms

--- 8.8.8.8 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 4.961/5.993/7.378/0.961 ms



Re: Package -stable updates

2019-08-29 Thread Consus
On 09:29 Thu 29 Aug, Florian Obser wrote:
> On Thu, Aug 29, 2019 at 09:39:40AM +0300, Consus wrote:
> > On 19:59 Wed 28 Aug, Steven Shockley wrote:
> > > So, many thanks to everyone who put together the new -stable updates for
> > > packages.  Is there a command I can put in the crontab that will only
> > > output if there are updates?  Similar to what syspatch or openup does.
> > > I tried pkg_add -unx, but that still tells me to delete old files and
> > > prints the quirks line even if there are no updates.
> > 
> > I use
> > 
> > 0 7 * * * pkg_add -un | grep -v 'signed on'
> > 
> > and it works okay, no warnings about deleting old files.
> > 
> > Though removing quirks line would be nice.
> > 
> 
> I thought you had moved on since stable packages are one or two
> decades too late?

Eh?



Re: Package -stable updates

2019-08-29 Thread Consus
On 19:59 Wed 28 Aug, Steven Shockley wrote:
> So, many thanks to everyone who put together the new -stable updates for
> packages.  Is there a command I can put in the crontab that will only
> output if there are updates?  Similar to what syspatch or openup does.
> I tried pkg_add -unx, but that still tells me to delete old files and
> prints the quirks line even if there are no updates.

I use

0 7 * * * pkg_add -un | grep -v 'signed on'

and it works okay, no warnings about deleting old files.

Though removing quirks line would be nice.



Re: OpenBSD -stable binary packages

2019-08-14 Thread Consus
On 15:30 Wed 14 Aug, Thomas Bohl wrote:
> https://marc.info/?l=openbsd-announce=156577865917831=2
> 
> > We are pleased to announce that we now also provide selected binary
> > packages for the most recent release. These are built from the -stable
> > ports tree which receives security and a few other important fixes:
> 
> Thank you!
> That is really cool.

A decade or two late, but still a great job. Worth re-establishing
monthly donations, I guess.



Re: Bluetooth support status

2019-08-07 Thread Consus
On 17:12 Tue 06 Aug, John Brahy wrote:
> Hello,
> 
> Just curious if there was any change in OpenBSD supporting bluetooth.

Sadly, there is none.



Re: When will OpenBSD become a friendly place for bug reporters?

2019-07-10 Thread Consus
On 17:14 Wed 10 Jul, Juan Francisco Cantero Hurtado wrote:
> On Wed, Jul 10, 2019 at 09:30:56AM +0300, Consus wrote:
> > On 18:56 Tue 09 Jul, Roderick wrote:
> > > 
> > > On Tue, 9 Jul 2019, cho...@jtan.com wrote:
> > > 
> > > > Perhaps rather than whining that OpenBSD lacks some specific feature,
> > > > those who want it could write it?
> > > 
> > > Or perhaps better not. All depends on what is a feature and for whom.
> > > 
> > > I, as normal user, am glad that packages are not inflated with debugging
> > > symbols.
> > 
> > That's why redhat and others offer *-debuginfo packages with DWARF
> > symbols. It's really helpful. It would be nice to have such in OpenBSD,
> > especially for base, because rebuilding something on my router is not
> > something I would like to do.
> 
> The symbols are included in the base libraries. We only strip the
> symbols in the packages. Try this on your router:
> objdump -x /usr/lib/libedit.so.* (just an example)

Yeah, but it's still stripped for tools (try gdb $(which smtpd) for
example).



Re: When will OpenBSD become a friendly place for bug reporters?

2019-07-10 Thread Consus
On 18:56 Tue 09 Jul, Roderick wrote:
> 
> On Tue, 9 Jul 2019, cho...@jtan.com wrote:
> 
> > Perhaps rather than whining that OpenBSD lacks some specific feature,
> > those who want it could write it?
> 
> Or perhaps better not. All depends on what is a feature and for whom.
> 
> I, as normal user, am glad that packages are not inflated with debugging
> symbols.

That's why redhat and others offer *-debuginfo packages with DWARF
symbols. It's really helpful. It would be nice to have such in OpenBSD,
especially for base, because rebuilding something on my router is not
something I would like to do.



Re: Filesystem corruption on OpenBSD routers after power outage?

2019-06-07 Thread Consus
On 19:30 Tue 04 Jun, Mogens Jensen wrote:
> I'm going to build a router for use in a remote location, and I have
> chosen OpenBSD 6.5 for the task. Unfortunately, it's not possible to
> protect the router with an UPS, so it will have to be resilient enough
> to survive sudden power outages and still boot without manual
> intervention.
> 
> In the past I have built a few Linux based routers and they were
> configured to run from RAM. I have made some research to see if this is
> also possible on OpenBSD and found that, while there are solutions to
> have / read-only, none of this is officially supported.
> 
> Can anyone with experience running OpenBSD routers without UPS, tell if
> filesystem corruption is going to be a problem after power outages, or
> if there are any officially supported ways to make the system resilient
> enough to not break after a power outage?
> 
> I'm using an mSATA disk with MLC flash in the router.
> 
> Thanks in advance.

I've had a couple of issues with my APU2-based router on 6.4. After the
power outage the newly linked kernel was corrupted, and some files ended
up in lost+found.



Re: When will be created a great desktop experience for OpenBSD?

2019-05-11 Thread Consus
On 10:29 Fri 10 May, Stuart Henderson wrote:
> On 2019-05-08, Consus  wrote:
> > On 02:01 Tue 07 May, Clark Block wrote:
> >> When will be created a great desktop experience for OpenBSD?
> >
> > After binary package updates will be out-of-box, without using
> > third-party M:Tier.
> 
> Oh, but they already are. Install snapshots instead of release.

Ain't -current a "development" branch? I mean things break, major
changes being pushed, experiments are being held. Kinda not what I want
on my home computer.



Re: When will be created a great desktop experience for OpenBSD?

2019-05-08 Thread Consus
On 02:01 Tue 07 May, Clark Block wrote:
> When will be created a great desktop experience for OpenBSD?

After binary package updates will be out-of-box, without using
third-party M:Tier.



Re: Upgrade procedure (6.4 -> 6.5)

2019-05-03 Thread Consus
On 15:08 Thu 02 May, Ingo Schwarze wrote:
> Hi Nick,
> 
> Nick Holland wrote on Thu, May 02, 2019 at 08:04:32AM -0400:
> 
> > There is no promise that an upgraded machine will be file-for-file
> > identical to a fresh install.  Here is the list of problems this might
> > cause you, as you can see, it's a long list and quite horrible:
> > 
> > * If you use the same hw for 20 years, you might run out of disk space?
> > 
> > Ok, not very long and not very horrible.
> > 
> > You are trying to solve a non-problem.  And sometimes, 'specially on an
> > upgraded machine, it's great to see how things WERE when the machine was
> > set up.  If you really care, go ahead, delete stuff.
> 
> There is (at least) one slight issue that doesn't have an official
> solution yet: manual pages.
> 
> It might be a good idea to do
> 
>   # rm -rf /usr/share/man/* /usr/X11R6/man/*
> 
> immediately before an upgrade.
> 
> If you don't do that, man(1) might serve you stale manual pages
> afterwards that were removed from the sets, containing information
> that no longer applies.
> 
> All the same, so far, we don't officially recommend it, and even i
> usually forget about it when doing upgrades.
> 
> Should that be automated?  Or are there risks of downsides or side
> effects?  I'm not sure.  Either way, it's hardly a very serious
> problem, it's merely slightly annoying.
> 
> Yours,
>   Ingo

Maybe it's a good idea to note this on the upgrade page? Something like
"the upgrade procedure may leave some files behing; you can manually
clean them up using sysclean package"?



Re: Upgrade procedure (6.4 -> 6.5)

2019-05-02 Thread Consus
On 09:42 Thu 02 May, Stuart Henderson wrote:
> The upgrade notes only list files which are likely to cause a problem
> if they're left lying around.

Oh, okay.



Re: Upgrade procedure (6.4 -> 6.5)

2019-05-02 Thread Consus
On 10:27 Thu 02 May, Markus Hennecke wrote:
> Am 02.05.2019 um 09:52 schrieb Consus:
> > I've upgraded my systems from 6.4 to 6.5 without a glitch, but I see
> > that /etc/networks and some other files (like malloc.conf.5) are still
> > present, although there is no use for them in the new release.
> > 
> > Is there a reason why these files are not listed in "FIles to remove"?
> > Is there a way to track them? It's not like something gonna break, but
> > old configuration files (and manual pages) lying around can make
> > someone's life harder during the debug session.
> 
> Take a look at the sysutils/sysclean port.

That's pretty much how I discovered this. But I want to know the
"official" way. Maybe there is a reason why e.g. perl files are to be
removed, but man pages are not.



Upgrade procedure (6.4 -> 6.5)

2019-05-02 Thread Consus
Hi,

I've upgraded my systems from 6.4 to 6.5 without a glitch, but I see
that /etc/networks and some other files (like malloc.conf.5) are still
present, although there is no use for them in the new release.

Is there a reason why these files are not listed in "FIles to remove"?
Is there a way to track them? It's not like something gonna break, but
old configuration files (and manual pages) lying around can make
someone's life harder during the debug session.



Re: Malloc config became global sysctl in 6.5

2019-04-27 Thread Consus
On 12:43 Sat 27 Apr, Thomas Frohwein wrote:
> Move along, nothing to see here.

I want to see more butthurting Theo!



Re: Malloc config became global sysctl in 6.5

2019-04-27 Thread Consus
I like reading misc@ mostly due to the constanst BUTTHURT that is going
on here.

But seriously though, each program can change it's own malloc flags
either by calling setenv(3) or just by updating static malloc_options
variable. So there is really *NO* difference between your old way
(/etc/malloc.conf) and your new way (setenv MALLOC_OPTIONS). There is a
possibility that a program will reset it's own env, but it would most
likely not.



Re: Request for testing

2019-01-04 Thread Consus
On 13:05 Fri 04 Jan, Otto Moerbeek wrote:
> On Fri, Jan 04, 2019 at 01:05:37PM +0300, Consus wrote:
> 
> > On 08:17 Fri 04 Jan, Otto Moerbeek wrote:
> > > Hi,
> > > 
> > > If you ever thought about getting more involved and learning a bit
> > > about buikdling a current OpenBSD, there's a call for testing at
> > > 
> > > https://marc.info/?l=openbsd-tech=154521488707434=2
> > > 
> > > Testing would provide me with valuable data about performance of
> > > memory management in multi-threaded applications.
> > 
> > Whay kind of performance (e.g. more/less responssive application)? Any
> > particular improvements should be looked for? Does number of CPUs
> > matter?
> > 
> 
> Responsiveness would be a main thing to look for. You might also have
> some other benchmark. Number of CPUs likely matters, that's one of the
> things I'm trying to find out.
> 
>   -Otto

Okay, I'll test some stuff on Ryzen 1800X by the end of this week. If
you have some particular test in mind, shoot.



Re: Request for testing

2019-01-04 Thread Consus
On 08:17 Fri 04 Jan, Otto Moerbeek wrote:
> Hi,
> 
> If you ever thought about getting more involved and learning a bit
> about buikdling a current OpenBSD, there's a call for testing at
> 
> https://marc.info/?l=openbsd-tech=154521488707434=2
> 
> Testing would provide me with valuable data about performance of
> memory management in multi-threaded applications.

Whay kind of performance (e.g. more/less responssive application)? Any
particular improvements should be looked for? Does number of CPUs
matter?



Re: netstat *:* udp sockets

2018-12-17 Thread Consus
On 08:25 Mon 17 Dec, Claudio Jeker wrote:
> On Sun, Dec 16, 2018 at 05:09:06PM -0500, Ted Unangst wrote:
> > Claudio Jeker wrote:
> > > On Fri, Dec 14, 2018 at 01:26:25PM -0500, Ted Unangst wrote:
> > > > Philip Guenther wrote:
> > > > > And, perhaps more directly, how would I block this in pf.conf?
> > > > > >
> > > > > 
> > > > > Excellent choice, blocking dhclient from receiving the leases that it
> > > > > requests.
> > > > > "What problem are you trying to solve?"
> > > > 
> > > > Well, this may be something of a lost cause, but I would prefer that 
> > > > chrome
> > > > not listen for stuff I don't understand. It listens on port 5353 as 
> > > > well, for
> > > > mDNS, and I can block that easily enough. It's the socket without a port
> > > > that's giving me trouble.
> > > 
> > > But a socket without a port is not listening on anything. It will not get
> > > any packets. It does not need to be filtered. This is how UDP works, it is
> > > a connectionless protocol.
> > 
> > ok, thank you, I was confused because they show up in netstat -ln too. I 
> > guess
> > that's just historic how it is behavior.
> 
> I guess we should change that. Problem is that UDP does not support
> listen(2) and so there is no listening state. Should netstat exclude all
> of UDP when using -l or what should it show? Only sockets that are bound
> but not connected (local port != 0 but remote addr/port = 0)?

A listening socket is a socket that can "accept" new "connections" --
it's possible to send data to it from some new host (e.g. via sendto).

So

local_port  != 0
remote_addr == NULL

is perfectly fine IMO.



Re: netstat *:* udp sockets

2018-12-14 Thread Consus
On 13:38 Thu 13 Dec, Ted Unangst wrote:
> netstat -an tells me I am listening to all the udp.
> 
> Active Internet connections (including servers)
> Proto   Recv-Q Send-Q  Local Address  Foreign Address(state)
> udp  0  0  *.**.*   
> udp  0  0  127.0.0.1.53   *.*   
> udp  0  0  *.**.*   
> udp  0  0  *.5353 *.*   
> udp  0  0  *.**.*   
> 
> What are those *.* sockets doing? How can you listen to all the ports?
> 
> According to fstat, two belong to dhclient and one to chrome.
> 
> root dhclient   552413* internet dgram udp *:0
> root dhclient   552415* internet dgram udp *:0
> tedu chrome 52839  107* internet dgram udp *:0
> 
> Although now they are printed as *:0. How do such sockets work?
> 
> And, perhaps more directly, how would I block this in pf.conf?

Wait, ain't

$ netstat -anl

should be used to get _listening_ sockets?



Re: Core Dev?

2018-12-03 Thread Consus
On 00:17 Tue 04 Dec, Ahmad Bilal wrote:
> Can anyone tell me,
> Is Antoine Jacoutot a core openbsd developer?
> 
> And this is his account (not a impersonator?)
> https://github.com/ajacoutot/aws-openbsd
> 
> Should I take it as a official way of running OpenBSD on AWS?

A quote from the source:

> Running whatever is in this repo will propably end up destroying a kitten 
> factory.

So probably not :)



Re: syntax error and doas.conf

2018-10-31 Thread Consus
On 10:42 Wed 31 Oct, Markus Rosjat wrote:
> Hi all,
> 
> just something I notice while trying out stuff with doas and my python
> scripts. If you do a mistake and have a syntax error in the doas.conf file
> you can easily look you self out from root privilages  :(
> 
> consider a a case where your root has no pw, you are the guy in the wheel
> group and of course you have only this line
> 
> permit persist keepenv :wheel
> 
> so far everything is peachy ok we are going to add a new line
> 
> permit nopass foo as root cmt /root/scripts/dosomething
> 
> and we save it ... ups we did a mistake an like to fix it, no worries we can
> ... or cant we?
> 
> doas vi /etc/doas.conf
> 
> doas: syntax error at line 15
> 
> 
> at this point you are a bit screwed because you cant edit the doas.conf you
> cant reboot you only way seems to be a switch off. Ok maybe there other was
> but hey I'm no pro Im a simple user and its a vm so switch it off. Boot in
> single user mode, make a fsck because , mount the patritions, export the
> TERM var so yu get a vi. Well seems we are back in business but no we cant
> edit /etc/doas.conf. Doesnt matter we came so far we simply copy the exmaple
> to /etc and be done with it. At that point 5 to 10 min of your life is
> wasted with silly stuff but you may have learn at least one thing ... read
> again what you just wrote before you save it :)
> 
> 
> Have a nice day list :) and happy helloween

Well, that's why we have sudoedit. With doas your are forced to

$ doas cp -p /etc/doas.conf /etc/doas.conf.new
$ doas vi /etc/doas.conf.new
$ doas -C /etc/doas.conf.new
$ doas mv /etc/doas.conf.new /etc/doas.conf



Re: APU2 and Spectre

2018-09-11 Thread Consus
On 21:11 Mon 10 Sep, Zbyszek Żółkiewski wrote:
> 
> > Wiadomość napisana przez Consus  w dniu 25.08.2018, o 
> > godz. 17:08:
> > 
> > Seems like APU2 board is vulnerable to Spectre:
> 
> seems there is microcode update with mitigations but looks like none want to 
> claim where that microcode comes from:
> 
> https://github.com/pcengines/apu2-documentation/issues/75
> 
> did someone try to load it from obsd? is it possible?

There is an unofficial binary with unknown origin. Seems like AMD have
sent microcode updates to some motherboard manufacturers, but there is
no hard proof though.



APU2 and Spectre

2018-08-25 Thread Consus
Hi,

Seems like APU2 board is vulnerable to Spectre:

$ uname -r
6.3
$ dmesg | grep cpu0 | grep AMD
cpu0: AMD GX-412TC SOC, 998.27 MHz
$ git clone https://github.com/crozone/SpectrePoC
$ cd SpectrePoC
$ gmake
$ ./spectre.out 85
Using a cache hit threshold of 85.
Build: RDTSCP_SUPPORTED MFENCE_SUPPORTED CLFLUSH_SUPPORTED 
INTEL_MITIGATION_DISABLED LINUX_KERNEL_MITIGATION_DISABLED
Reading 40 bytes:
Reading at malicious_x = 0xffeff180... Success: 0x54=’T’ score=2
Reading at malicious_x = 0xffeff181... Success: 0x68=’h’ score=2
Reading at malicious_x = 0xffeff182... Success: 0x65=’e’ score=2
Reading at malicious_x = 0xffeff183... Success: 0x20=’ ’ score=2
Reading at malicious_x = 0xffeff184... Success: 0x4D=’M’ score=2
Reading at malicious_x = 0xffeff185... Success: 0x61=’a’ score=2
Reading at malicious_x = 0xffeff186... Success: 0x67=’g’ score=2
Reading at malicious_x = 0xffeff187... Success: 0x69=’i’ score=2
Reading at malicious_x = 0xffeff188... Success: 0x63=’c’ score=2
Reading at malicious_x = 0xffeff189... Success: 0x20=’ ’ score=2
Reading at malicious_x = 0xffeff18a... Success: 0x57=’W’ score=2
Reading at malicious_x = 0xffeff18b... Success: 0x6F=’o’ score=2
Reading at malicious_x = 0xffeff18c... Success: 0x72=’r’ score=2
Reading at malicious_x = 0xffeff18d... Success: 0x64=’d’ score=2
Reading at malicious_x = 0xffeff18e... Success: 0x73=’s’ score=2
Reading at malicious_x = 0xffeff18f... Success: 0x20=’ ’ score=2
Reading at malicious_x = 0xffeff190... Success: 0x61=’a’ score=2
Reading at malicious_x = 0xffeff191... Success: 0x72=’r’ score=2
Reading at malicious_x = 0xffeff192... Success: 0x65=’e’ score=2
Reading at malicious_x = 0xffeff193... Success: 0x20=’ ’ score=2
Reading at malicious_x = 0xffeff194... Success: 0x53=’S’ score=2
Reading at malicious_x = 0xffeff195... Success: 0x71=’q’ score=2
Reading at malicious_x = 0xffeff196... Success: 0x75=’u’ score=2
Reading at malicious_x = 0xffeff197... Success: 0x65=’e’ score=2
Reading at malicious_x = 0xffeff198... Success: 0x61=’a’ score=2
Reading at malicious_x = 0xffeff199... Success: 0x6D=’m’ score=2
Reading at malicious_x = 0xffeff19a... Success: 0x69=’i’ score=2
Reading at malicious_x = 0xffeff19b... Success: 0x73=’s’ score=2
Reading at malicious_x = 0xffeff19c... Success: 0x68=’h’ score=2
Reading at malicious_x = 0xffeff19d... Success: 0x20=’ ’ score=2
Reading at malicious_x = 0xffeff19e... Success: 0x4F=’O’ score=2
Reading at malicious_x = 0xffeff19f... Success: 0x73=’s’ score=2
Reading at malicious_x = 0xffeff1a0... Success: 0x73=’s’ score=2
Reading at malicious_x = 0xffeff1a1... Success: 0x69=’i’ score=2
Reading at malicious_x = 0xffeff1a2... Success: 0x66=’f’ score=2
Reading at malicious_x = 0xffeff1a3... Success: 0x72=’r’ score=2
Reading at malicious_x = 0xffeff1a4... Success: 0x61=’a’ score=2
Reading at malicious_x = 0xffeff1a5... Success: 0x67=’g’ score=2
Reading at malicious_x = 0xffeff1a6... Success: 0x65=’e’ score=2
Reading at malicious_x = 0xffeff1a7... Success: 0x2E=’.’ score=2

I've double-checked output of syspatch(1) and fw_update(1) but no
pending updates exist. Am I missing something or there is no mitigation
for this AMD CPU family?



Re: wifi gui manager

2018-08-22 Thread Consus
On 00:22 Wed 22 Aug, Anthony J. Bentley wrote:
> Consus writes:
> > On 18:07 Tue 21 Aug, Stuart Henderson wrote:
> > > On 2018-08-21, Consus  wrote:
> > > > On 15:05 Tue 21 Aug, Stuart Henderson wrote:
> > > >> > Also what's wrong with gitlab/github?
> > > >> 
> > > >> They encourage devs to be lazy and not produce proper stable release 
> > > >> ass
> > ets.
> > > >> Lots of mess in the ports tree from people who just tag something on 
> > > >> git
> > hub,
> > > >> don't produce a stable tarball, don't generate autoconf scripts etc.
> > > >
> > > > What do you mean by "stable tarball"? If a tag contains stable version
> > > > of code you just download the tarball that is generated for the tag.
> > > 
> > > So you are part of the problem!
> > > 
> > > I mean a tarball that is generated once and not change, rather than 
> > > somethi
> > ng
> > > which changes depending on what software is installed on the cluster node.
> >
> > If you create a release
> > (https://help.github.com/articles/creating-releases/) then all
> > associated generated tarballs are immutable, as far as I know.
> 
> They're not immutable.

The ones that you associate with with release? You sure?



Re: wifi gui manager

2018-08-21 Thread Consus
On 18:07 Tue 21 Aug, Stuart Henderson wrote:
> On 2018-08-21, Consus  wrote:
> > On 15:05 Tue 21 Aug, Stuart Henderson wrote:
> >> > Also what's wrong with gitlab/github?
> >> 
> >> They encourage devs to be lazy and not produce proper stable release 
> >> assets.
> >> Lots of mess in the ports tree from people who just tag something on 
> >> github,
> >> don't produce a stable tarball, don't generate autoconf scripts etc.
> >
> > What do you mean by "stable tarball"? If a tag contains stable version
> > of code you just download the tarball that is generated for the tag.
> 
> So you are part of the problem!
> 
> I mean a tarball that is generated once and not change, rather than something
> which changes depending on what software is installed on the cluster node.

If you create a release
(https://help.github.com/articles/creating-releases/) then all
associated generated tarballs are immutable, as far as I know.
 
> > Also autolulz are slow and ugly, please use plain Makefile for C
> > projects.
> 
> They're even slower and uglier if you have to run the m4 stuff to *generate*
> them before you can even run them, and may not work as intended if they're
> run through a version of autoconf which they weren't designed for.

That's why we should nuke autloluz in favor of something else. Just
plain Makefiles for example. Or meson, I heard it's okay.



Re: wifi gui manager

2018-08-21 Thread Consus
On 15:05 Tue 21 Aug, Stuart Henderson wrote:
> > Also what's wrong with gitlab/github?
> 
> They encourage devs to be lazy and not produce proper stable release assets.
> Lots of mess in the ports tree from people who just tag something on github,
> don't produce a stable tarball, don't generate autoconf scripts etc.

What do you mean by "stable tarball"? If a tag contains stable version
of code you just download the tarball that is generated for the tag.
Also autolulz are slow and ugly, please use plain Makefile for C
projects.



Re: wifi gui manager

2018-08-21 Thread Consus
On 10:46 Tue 21 Aug, Stuart Henderson wrote:
> On 2018-08-20, Consus  wrote:
> > Oh my god, why sourceforge?
> 
> Why not? At least it's not gitlab or github!

It's been known for embedding spam in zip archives. Also what's wrong
with gitlab/github?



Re: wifi gui manager

2018-08-20 Thread Consus
On 22:34 Sun 19 Aug, Edgar Pettijohn III wrote:
> I've written a simple gui wifi manager. It can be found at:
> 
> https://sourceforge.net/projects/openbsd-wifi-manager/

Oh my god, why sourceforge?



Re: Status of Owncloud?

2018-07-23 Thread Consus
On 16:25 Sun 22 Jul, Rupert Gallagher wrote:
> Nextcloud, a government-funded project to keep your data secure...
> Hold on to your buts, here it comes.

DARPA, OpenBSD... Rings a bell?



Re: Limit CPU usage of a process?

2018-05-27 Thread Consus
On 20:02 Sun 27 May, Kevin Chadwick wrote:
> Umatrix is a good javascript control extension. Some websites are even
> running bitcoin mining without asking your permission. Theft of
> electricity in my book.

Hell, javascript itself is a theft of electricity.



Re: Checking my new smtpd.conf syntax

2018-05-25 Thread Consus
On 15:20 Fri 25 May, Gilles Chehade wrote:
> no matter the keywords, there's no way 100% people would be satisfied :)
> 
> be happy, first iteration was "match [...] => foobar", now 'action'
> does not look so bad hu ?

Guess so :D



Re: Checking my new smtpd.conf syntax

2018-05-25 Thread Consus
On 15:14 Fri 25 May, Gilles Chehade wrote:
> On Fri, May 25, 2018 at 03:58:59PM +0300, Consus wrote:
> > On 14:31 Fri 25 May, Gilles Chehade wrote:
> > > On Fri, May 25, 2018 at 02:20:50PM +0200, Walter Alejandro Iglesias wrote:
> > > > Could someone tell me if my changes below are OK. :-)
> > > > 
> > > > The part I'm not clear is I read in current.html remote authenticated
> > > > users need a explicit rule.  Do I need to add some "match auth" rule?
> > > > 
> > > 
> > > yes.
> > > 
> > > before, "from local" would match authenticated users as if they had sent
> > > mail from the local machine but this led to being unable to express some
> > > setups where depending on the source you want to relay to different hubs
> > > even though users are authenticated.
> > > 
> > > 
> > > With this:
> > > 
> > > > match from local for local apply local_users
> > > > match from any for domain  virtual  apply 
> > > > local_users
> > > > match from local sender  for any apply remote_users
> > > 
> > > you need an additonal rule such as:
> > > 
> > > match auth from any sender  for any apply remote_users
> > > 
> > > 
> > > because:
> > > 
> > > > #accept from local sender  for any relay
> > > 
> > > no longer matches authenticated users
> > 
> > Ain't it "action local_users" instead of "apply local_users"? The man
> > page states "action".
> 
> oopsie, yes, action, forget about apply, it doesn't exist, I should not
> answer mail while talking on the phone :-)

Frankly, I like apply better :(



Re: Checking my new smtpd.conf syntax

2018-05-25 Thread Consus
On 14:31 Fri 25 May, Gilles Chehade wrote:
> On Fri, May 25, 2018 at 02:20:50PM +0200, Walter Alejandro Iglesias wrote:
> > Could someone tell me if my changes below are OK. :-)
> > 
> > The part I'm not clear is I read in current.html remote authenticated
> > users need a explicit rule.  Do I need to add some "match auth" rule?
> > 
> 
> yes.
> 
> before, "from local" would match authenticated users as if they had sent
> mail from the local machine but this led to being unable to express some
> setups where depending on the source you want to relay to different hubs
> even though users are authenticated.
> 
> 
> With this:
> 
> > match from local for local apply local_users
> > match from any for domain  virtual  apply local_users
> > match from local sender  for any apply remote_users
> 
> you need an additonal rule such as:
> 
> match auth from any sender  for any apply remote_users
> 
> 
> because:
> 
> > #accept from local sender  for any relay
> 
> no longer matches authenticated users

Ain't it "action local_users" instead of "apply local_users"? The man
page states "action".



Re: opensmtpd / ldap unreliable

2018-05-24 Thread Consus
On 17:20 Wed 23 May, Allan Streib wrote:
> "Paul B. Henson"  writes:
> 
> >> What you ask is a very general question: If A depends on B, and B is
> >> missing, how do expect A to behave?
> >
> > In this specific case, I expect A to complain it was unable to contact
> > B, to continue initializing, return temporary failures for any
> > operation which requires B, and reattempt a connection to B on a
> > regular basis until it is successful. From a reliability and full
> > tolerance perspective, falling over and dying doesn't seem a very good
> > choice for the circumstances.
> 
> Falling over and dying is the simplest thing. It makes no assumptions
> about the cause of the problem and when it might be resolved. It does
> not attempt to carry on in some hobbled fashion, possibly creating
> further problems.
> 
> If you depend on services being up, you will need monitors/supervisors
> to detect when they are not up, and attempt restarts and/or notify you
> as appropriate. Baking this into the services themselves is a
> duplication of functionality that can be handled externally.
> 
> Allan

So... your web browser crashes when there is no network, right?



Re: Viewport for man.openbsd.org -- readability on phones

2018-05-16 Thread Consus
On 00:26 Wed 16 May, Solene Rapenne wrote:
> See no offence here, I wonder what is the context leading to read man
> pages on a phone?

Because OpenBSD distributes it's documentation in man pages. There is
no standalone documentation site.



Re: NFS keeps crashing

2018-04-21 Thread Consus
On 18:38 Sat 21 Apr, IL Ka wrote:
> >  I mean sponsors who pay for projects and compatibility updates. I also
> > mean broader user base.
> 
> I belive NFS is rarely used nowadays, especially with Windows clients.
> People use samba/smb to connect *nix to Windows in most cases.
> Samba should be pretty stable because OS X uses it to coexist with MS oses.

Samba is also very very slow if you consider 10G/100G networks. Support
for Multi-Channel is still marked as experimental and may kill your data.



Re: Virtualbox vs latest snapshot

2018-04-13 Thread Consus
On 09:30 Fri 13 Apr, Boudewijn Dijkstra wrote:
> The point is not to go to court, the point is to bully people into
> paying up.

Well, this reminds me of Nigerian Emails. Have someone actually payed
them? Cause seriously, you can just reply them with a goatse picture
attached. Even goatse has more legal matter in it.



Re: Virtualbox vs latest snapshot

2018-04-12 Thread Consus
On 08:28 Thu 12 Apr, Nick Holland wrote:
> Another "failure mode" of VirtualBox people should be aware of:
> I understand through good sources, Oracle monitors the IP addresses that
> it's downloaded from, and if they can trace it back to a commercial IP
> (i.e., not a home address), and if they see you download (or update) the
> "not for unrestricted free use" parts, their lawyers will contact you
> and send you a bill...and they really don't care about "for work" or
> "not for work related" uses.
> 
> I'd really recommend removing this product from your computers.

This won't stand in court. You sources are so high on crack it's not
even funny.



Re: bug tracking system for OpenBSD

2018-04-01 Thread Consus
On 11:01 Sun 01 Apr, Stuart Henderson wrote:
> Please don't.

I wasn't going to. This guy jsut asked for the feedback so I wrote him.



Re: bug tracking system for OpenBSD

2018-03-31 Thread Consus
On 21:04 Sat 31 Mar, Consus wrote:
> On 23:01 Fri 30 Mar, Sergey Bronnikov wrote:
> > I have made a first step forward in direction to OpenBSD bugtracker
> > and imported bugs@ archive to a Fossil SCM -
> > https://bronevichok.ru/cgi-bin/b.cgi/rptview?rn=1
> > Let's discuss a next step.
> 
> The first obvious problem: you've imported every message in the mailing
> list as a separate ticket:
> 
>   c541065d62 ... kernel/515: Byte-order confusion in CD-ROM drivers 
>   4136fcdc4e ... Re: kernel/515
> 
> or
> 
>   3989e0a08b ... documentation/532: man page 'curs_terminfo' does not 
> exist
>   0486b260d2 ... Re: documentation/532
> 
> So the main advantage of the bug tracking system (ability to follow the
> history of actions) is lost.
> 
> Or I got something wrong, the UI is kinda strange.

Oh, I got it. User comments are being added properly only if replies to

subsytem/id: subject

are in form

RE: subsystem/id: subject

which is not always the case as

RE: subsystem/id

is also frequent.

Also ALL tickets are opened.



Re: bug tracking system for OpenBSD

2018-03-31 Thread Consus
On 23:01 Fri 30 Mar, Sergey Bronnikov wrote:
> I have made a first step forward in direction to OpenBSD bugtracker
> and imported bugs@ archive to a Fossil SCM -
> https://bronevichok.ru/cgi-bin/b.cgi/rptview?rn=1
> Let's discuss a next step.

The first obvious problem: you've imported every message in the mailing
list as a separate ticket:

c541065d62 ... kernel/515: Byte-order confusion in CD-ROM drivers 
4136fcdc4e ... Re: kernel/515

or

3989e0a08b ... documentation/532: man page 'curs_terminfo' does not 
exist
0486b260d2 ... Re: documentation/532

So the main advantage of the bug tracking system (ability to follow the
history of actions) is lost.

Or I got something wrong, the UI is kinda strange.



Re: Why are so many people running and writing about current snapshots

2018-03-27 Thread Consus
On 14:46 Tue 27 Mar, Niels Kobschaetzki wrote:
> CentOS 5 is EOL since March 31st 2017 ;)
> CentOS 6 should be on extended support now which is going EOL in
> November 2020.

Yep. And Centos7 will be around until 2024. So 4/5 of Linux distros in
production (e.g. Alpine is different in this regard) are affected by
this awful megafreeze strategy when you're stuck with an old kernel and
tools (not everything gets backported) for years.

That's why I love OpenBSD's 6 month release cycles so much :3



Re: Why are so many people running and writing about current snapshots

2018-03-27 Thread Consus
On 22:31 Mon 26 Mar, Z Ero wrote:
> I just don't want OpenBSD to turn into Linux where the fixation is on
> newest shiny thing rather than doing code right. Sometimes I think
> people who are excessively interested in bleeding edge features more
> want an OS for tinkering with than an OS for production / work. I want
> something stable to use. But to each his own.

Err... how exactly megafreeze for several years is bleeding edge? I mean
there still are CentOS 5 installations in production. And it was
released in 2007.



Re: OpenBSD and IPMI

2018-03-09 Thread Consus
On 16:11 Fri 09 Mar, Denis wrote:
> By reading this article
> blog.rapid7.com/2013/07/02/a-penetration-testers-guide-to-ipmi/ my hair
> raised. 
> 
> How to OpenBSD security withstands against IPMI holed solution from top
> hardware vendors?
> 
> Best ways to prevent potential risks for OpenBSD over IPMI?

Make your IPMI network private.



Re: DNS-01 challenge in acme-client

2018-03-02 Thread Consus
On 19:27 Fri 02 Mar, Stuart Henderson wrote:
> On 2018-03-01, Consus <con...@ftml.net> wrote:
> > Let's Encrypt is going to support wildcard certificates soon enough, but
> > only through DNS-01 challenge, but acme-client(1) does not support it.
> > Have you guys considered implemeting DNS challenges?  Maybe someone is
> > already working on the implementation? If not are patches welcome?
> 
> Kristaps' original version of acme-client supports this, though you do
> need a script as well.

That's the most simple way do it, so I'm not surprised.
 
> It won't help for letsencrypt wildcard certificates yet because they
> require a new version of the ACME protocol.

Yes, but I think acme-client(1) should support ACME v2 anyway, because
it's not clear for how long Let's Encrypt will keep the legacy API
endpoints available.

> (I'm not a fan of wildcard certs anyway though, they mostly just
> encourage people to reuse certs and keys in places where they aren't
> necessary).

True, but wildcards come in handy in situations where you have a bunch
of generated and short-living (often per http-session) DNS records with
a common domain.



Re: DNS-01 challenge in acme-client

2018-03-02 Thread Consus
On 15:46 Fri 02 Mar, Consus wrote:
> On 11:45 Fri 02 Mar, Etienne wrote:
> > Well, really, what you're asking for is having acme-client offload the
> > complicated stuff (set the TXT records, then check for verification) to a
> > script, which to me looks pretty much the same as writing a script to do
> > everything.
> 
> I'm not. Writing TXT entries can be done the same way acme-client(1)
> handles TLS challenges now.

HTTP of course, not TLS. Sorry.



Re: DNS-01 challenge in acme-client

2018-03-02 Thread Consus
On 11:45 Fri 02 Mar, Etienne wrote:
> Well, really, what you're asking for is having acme-client offload the
> complicated stuff (set the TXT records, then check for verification) to a
> script, which to me looks pretty much the same as writing a script to do
> everything.

I'm not. Writing TXT entries can be done the same way acme-client(1)
handles TLS challenges now.

> I believe you'll see limited advantage in having acme-client do
> any work here, compared to having your script issue the CSR, send it to
> Letsencrypt, receive the TXT records, and do the rest of the complicated
> stuff mentioned above.

I'm not suggesting that we should put ALL this in a script. Ideally your
script should be like this:

#!/bin/sh
doas _acmedns nsd-control reload 

That's all. DNS challenge is only different from a TLS challenge in one
simple bit -- you need to reload your DNS server configuration before
answering to the ACME server.

> I think acme-client's value is where the certificate for a server, the
> server, and the verification challenge/process all take place on the same
> machine. But the DNS service is likely to be handled by another (or rather,
> many other) machine(s).

You can generate your certs in one place and then distribute them to
your frontends.



Re: DNS-01 challenge in acme-client

2018-03-01 Thread Consus
On 15:20 Thu 01 Mar, Solène Rapenne wrote:
> It is not easy to implement because this requires access to your
> DNS server (like nsd or bind) or your registrar admin API which would
> require adding plugins for each API.

Well... that's why it's called DNS challenge, right?

> It is more complicated than creating a file in a folder.

With a little luck it's not. Both NSD and BIND allow you to include
files in zone configuration like this:

/path/to/your/zones/zone.foo.bar
/path/to/your/zones/zone.foo.bar.acme.inc

So the whole process possibly boils down to
this:

1. Receive a challenge
2. Write TXT record to a file
3. Politely ask your DNS daemon to reload the zone
4. Reply to the ACME server
5. Grab your certificates

The only problem here is #3, but it's possible to create e.g. another
pledged process that can only execute /etc/acme-client/dns-challenge.sh
and you can put all your complicated stuff there.



DNS-01 challenge in acme-client

2018-03-01 Thread Consus
Hi,

Let's Encrypt is going to support wildcard certificates soon enough, but
only through DNS-01 challenge, but acme-client(1) does not support it.
Have you guys considered implemeting DNS challenges?  Maybe someone is
already working on the implementation? If not are patches welcome?



https://openbsd.org/users.html looks dated

2018-02-14 Thread Consus
Hi,

If anyone cares this page contains a bunch of dead links and
pr...@openbsd.org is an invalid recipient.



Re: considering a move to OpenBSD

2018-02-09 Thread Consus
On 13:02 Fri 09 Feb, Otto Moerbeek wrote:
> On Fri, Feb 09, 2018 at 12:27:47PM +0300, Consus wrote:
> 
> > On 23:12 Thu 08 Feb, Jeroen wrote:
> > > I can talk hours and hours why OpenBSD is superior to Linux
> > 
> > It is possible to list all block devices (with type and size) with one
> > command? You now, like lsblk(8) in Linux.
> 
> I don't think there's a single command that covers that. By
> look at sysctl hw.disknames and disklabel.
> 
> But some points I'd like to make
> 
> - Only you can decide if OpenBSD fits you and if you like the way
>   things work.

Of course. I quite like it on my router. It works marvelous.
 
> - You have to expect some/a lot of things to be different compared to
>   Linux. While both systems implement Posix, the general approach
>   differs a lot. Some things differ for a reason, historical or not.

I know.

> - You shouldn't assume we know Linux. So refering to a Linux specific
>   command often does not help a lot. Try to explain what you want to
>   achieve.

I was just making a point. OpenBSD has a lot of downsides in some areas
so blindly calling it 'superior to Linux' without knowing the actual use
cases is kinda naive.

> - Use the man pages and FAQ. We've put quite some effort into them.

Keep up the good work.



Re: considering a move to OpenBSD

2018-02-09 Thread Consus
On 10:40 Fri 09 Feb, Philipp Buehler wrote:
> Am 09.02.2018 10:27 schrieb Consus:
> > It is possible to list all block devices (with type and size) with one
> > command? You now, like lsblk(8) in Linux.
> 
> You're implying..
> 
> # lsblk
> bash: lsblk: command not found
> 
> And just that is already a reason, I do not like "Linux" very much.

I'm implying this:

# lsblk
NAMEMAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
nvme0n1 259:00 238.5G  0 disk
├─nvme0n1p1 259:10   256M  0 part /boot/efi
├─nvme0n1p2 259:20   256M  0 part /boot
└─nvme0n1p3 259:30   238G  0 part
  ├─laptop-root 253:0032G  0 lvm  /
  ├─laptop-swap 253:1016G  0 lvm
  └─laptop-home 253:20   190G  0 lvm  /home

I also can see RAIDs here (I do not have one on my laptop though). How
do I get something similar on OpenBSD?



Re: considering a move to OpenBSD

2018-02-09 Thread Consus
On 23:12 Thu 08 Feb, Jeroen wrote:
> I can talk hours and hours why OpenBSD is superior to Linux

It is possible to list all block devices (with type and size) with one
command? You now, like lsblk(8) in Linux.



Re: Options for dealing with DES crypt password file

2018-01-11 Thread Consus
On 18:27 Thu 11 Jan, Jeff Zimmerman wrote:
> I've got an old server (OpenBSD 4.7 old) with a mixed bag of password
> hashes in master.passwd. A majority of the passwords (hundreds) are
> old salted DES crypt format.
> 
> Am I correct in my research that everything but Blowfish was removed
> from crypt() around OpenBSD 5.7? Are there any workarounds for me
> using the old DES password hashes, or do we need to 'passwd '
> for hundreds of users?

Use LDAP already.



Re: OpenBSD and virtual machines

2018-01-09 Thread Consus
On 22:14 Mon 08 Jan, Sterling Archer wrote:
> Trolls.

High-fat food is no good for one's health!



Re: OpenBSD and virtual machines

2018-01-08 Thread Consus
On 16:37 Mon 08 Jan, Galaxy Júpiter wrote:
> Why OpenBSD now have their own native virtualisation layer?
> Why Theo de Raadt changed your opinion about virtual machines?
> What is the current opinion of Theo de Raadt about virtual machines?

What does Theo de Raadt eat for breakfast?



Re: Kindly support this initiative for a public git repository of OpenBSD source code located at Germany!

2017-12-30 Thread Consus
On 23:35 Thu 28 Dec, Dinesh Thirumurthy wrote:
> Dear Everyone,
> 
> On Thu, Dec 28, 2017 at 3:05 PM, Mikko Laine  wrote:
> 
> > You could try https://notabug.org/, which is Dutch-owned and hosted in
> > Germany. Note larger repositories (>100 Mb) are accepted per-case.
> 
> 
> I have requested notabug.org to provide 1GB space for openbsd src git repo.
> It would be good to demonstrate that that you also want this idea
> implemented.
> 
> So, kindly help by voting Yes to my online poll.
> 
> The poll is at https://doodle.com/poll/rbg53x3dyd7i4y5d
> 
> Thanks very much.

There is a github mirror already, nah?



Re: Read sysctl from file

2017-07-20 Thread Consus
On 07:08 Thu 20 Jul, Kai Wetlesen wrote:
> > Because it's a nice way to apply configuration changes made to
> > /etc/sysctl.conf without restarting the whole server?
> 
> Systemctl doesn't offer hot reload unless the controlled daemon offers
> the capability in the first place. The only thing systemd does is hits
> the controlling process on the head with a known conf-reload signal or
> (gasp) a DBus control statement. Both of these can be done just as
> well with an rc script, and without restarting the service.

What systemd has to do with anything? We are talking about sysctl(8) and
sysctl.conf(5).



Re: Read sysctl from file

2017-07-20 Thread Consus
On 07:45 Thu 20 Jul, Theo de Raadt wrote:
> > On 07:39 Thu 20 Jul, Theo de Raadt wrote:
> > > someone in linux land went off the map here.  and then another piece of
> > > software started un-portably assuming that's the way to do things?
> > 
> > Because it's a nice way to apply configuration changes made to
> > /etc/sysctl.conf without restarting the whole server?
> 
> only thinking of yourself, and missing the point.
> 
> the point is that the 25-year old sysctl design had no such feature,
> and now other things are changing that.
> 
> No, what you want does not exist.

He just asks if OpenBSD supports such a feature. Why so butthurt?



Re: Read sysctl from file

2017-07-20 Thread Consus
On 07:39 Thu 20 Jul, Theo de Raadt wrote:
> someone in linux land went off the map here.  and then another piece of
> software started un-portably assuming that's the way to do things?

Because it's a nice way to apply configuration changes made to
/etc/sysctl.conf without restarting the whole server?



Re: Sad story

2017-06-05 Thread Consus
On 13:37 Mon 05 Jun, Ingo Schwarze wrote:
> L. R. S. wrote on Mon, Jun 05, 2017 at 12:14:51PM +0200:
> 
> > Forgot the passphrase of a full-disk encrypted OpenBSD system ;_;
> > So many documents will be lost, like [coughs] accesses to NULL.
> 
> Simply restore from backup.

There are two types of system administrators...



Re: iked(8) OpenBSD road warrior setup anybody?

2016-10-04 Thread Consus
On 09:47 Tue 04 Oct, Pavel Korovin wrote:
> Discussed with Michael off-the-list and found that he has different
> setup where iked(8) is not involved.
> 
> Just in case, my question is about OpenBSD native iked(8) setup for
> remote access VPN gateway to serve OpenBSD native iked(8) client.
> If anybody has such setup and/or willing to discuss the details, please
> send me a message, I'd prefer to discuss this off-the-list.

It would be nice to have some post-mortem summary (probably a short
description of your setup + iked configuration files). Just in case
someone else will need it.



Re: can't find fstab entry ?

2016-09-10 Thread Consus
On 03:09 Mon 05 Sep, Theo de Raadt wrote:
> > OpenBSD 6.0 GENERIC.MP#0 amd64
> > 
> > My fstab entry looks like :
> > 
> > 10.10.10.10:/srv/share /mnt/ops_test nfs defaults,noexec,nosuid,nodev,auto 
> > 0 0
> > 
> > However:
> > 
> > $ doas mount /mnt/ops_test
> > doas (m...@example.com) password:
> > mount: can't find fstab entry for /mnt/ops_test
> > 
> > 
> > Any ideas  ?  That style of fstab entry seems to work fine on my linux
> > boxes (albeit with nfs4 instead of nfs, but that makes no difference
> > on openbsd).
> 
> Well, openbsd is not linux.
> 
> Have no idea what that word "defaults" in there means.

I guess it would've been better to say something like:

mount: unknown option "defaults" for /mnt/ops_test

Care for a patch?



Re: OpenBSD 6.0 release and errata60.html

2016-09-02 Thread Consus
On 11:14 Fri 02 Sep, Consus wrote:
> Yeah, you probably should. Also you can use M:Tier, they ship binary
> errata updates: https://stable.mtier.org

There is already a full set of binary patches. These guys are so sweet.



Re: OpenBSD 6.0 release and errata60.html

2016-09-02 Thread Consus
On 15:59 Thu 01 Sep, 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 ?
> 
> Thanks in advance,

Yeah, you probably should. Also you can use M:Tier, they ship binary
errata updates: https://stable.mtier.org



Re: LibreSSL on old OpenBSD

2016-08-12 Thread Consus
On 03:20 Fri 12 Aug, Anthony J. Bentley wrote:
> Roderick writes:
> > I know, you will complain, because I mention here that I still use
> > OpenBSD 4.8 in a machine.
> 
> Then why do you ask? Do you think people will happily take time to
> help you debug problems on a system that has been *explicitly*
> unsupported for the past five years?
> 
> > In file included from /usr/include/machine/endian.h:58,
> >   from ../include/compat/machine/endian.h:36,
> >   from rc4/rc4_enc.c:59:
> > /usr/include/sys/endian.h:162: error: expected '=', ',', ';', 'asm' or 
> > '__attribute__' before 'htobe64'
> > /usr/include/sys/endian.h:163: error: expected '=', ',', ';', 'asm' or 
> > '__attribute__' before 'htobe32'
> > /usr/include/sys/endian.h:164: error: expected '=', ',', ';', 'asm' or 
> > '__attribute__' before 'htobe16'
> > /usr/include/sys/endian.h:
> > <<
> > 
> > What did change here from OpenBSD 4.8 to the current versions? Is it an
> > esential change?
> 
> Did you look at the CVS history? Obviously not, or you would have seen
> right away that there have been *essential* changes to endian.h over the
> course of the last five years.
> 
> Or what, do you think that guenther's commits to our headers are meant
> to make them worse?

Oh, looky, OpenBSD butthurt again.



Re: github

2016-08-07 Thread Consus
On 18:12 Sun 07 Aug, ludovic coues wrote:
> 2016-08-07 18:00 GMT+02:00 Consus <con...@gmx.com>:
> > On 10:56 Sun 07 Aug, Chris Bennett wrote:
> >> On Sun, Aug 07, 2016 at 06:43:02PM +0300, Consus wrote:
> >> > Sign your commits with GPG. Looky, a link:
> >> >
> >> > https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work
> >> >
> >> > Not that hard, is it?
> >> >
> >>
> >> OK, you win.
> >>
> >> Would you do me a favor first.
> >> Before this big move, could you make a commit to the OpenBSD CVS tree?
> >> Anything would do. Just find a file that has spaces where it should have
> >> tabs. Commit your diff. Once you do that, I think all of the developers
> >> will be easily convinced to move to Github.
> >
> > Err... What?
> >
> 
> You are talking big while not contributing to the project.

So? I'm not stating YOU GUYS SHOULD MOVE TO GITHUB RIGHT NOW. I'm
stating that "github is not secure" is bullshit.



Re: github

2016-08-07 Thread Consus
On 10:56 Sun 07 Aug, Chris Bennett wrote:
> On Sun, Aug 07, 2016 at 06:43:02PM +0300, Consus wrote:
> > Sign your commits with GPG. Looky, a link:
> > 
> > https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work
> > 
> > Not that hard, is it?
> > 
> 
> OK, you win.
> 
> Would you do me a favor first.
> Before this big move, could you make a commit to the OpenBSD CVS tree?
> Anything would do. Just find a file that has spaces where it should have
> tabs. Commit your diff. Once you do that, I think all of the developers
> will be easily convinced to move to Github.

Err... What?



Re: github

2016-08-07 Thread Consus
On 10:35 Sun 07 Aug, Chris Bennett wrote:
> On Sun, Aug 07, 2016 at 11:17:21AM -0400, Donald Allen wrote:
> > > Date: Sun, 7 Aug 2016 17:59:07 +0300
> > > From: con...@gmx.com
> > > To:
> > misc@openbsd.org
> > > Subject: Re: github
> > > 
> > 
> > And github offers two-factor authentication, so if enabled, not simple
> > to hack the account.
> > 
> 
> Github is running OpenBSD? I didn't know that.
> That's a relief. I wouldn't trust any of my critical data with any less
> secure Operating Ayatem.

Sign your commits with GPG. Looky, a link:

https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work

Not that hard, is it?



Re: github

2016-08-07 Thread Consus
On 16:43 Sun 07 Aug, Ingo Schwarze wrote:
> > Do you have any plans to move the OpenBSD source code repository
> > to github?
> 
> Absolutely not.  The OpenBSD repository will remain secure and
> will not be outsourced to a random third party.

I'm sorry, are we talking about the same OpenBSD CVS tree that does not
offer any kind of encryption and transfers all your data in plain over
the network (except for developers who use SSH of course)? How's that
secure?

Moreover, Git itself allows you to check what the hell is going on using
your local history (e.g. git pull will not work without some love if
somebody changes your repo on the GitHub side without your awareness).
Also signed commits FWIW.



Re: tmpfs

2016-07-31 Thread Consus
On 23:02 Sun 31 Jul, mxb wrote:
> Mine is sane.

No, it's not. Your email contains valid UTF-8 symbols but mime states
that it is in us-ascii:

Content-Type: text/plain; charset="us-ascii"

Really, just shut up and fix it. It's that simple :)



Re: tmpfs

2016-07-31 Thread Consus
On 20:53 Sun 31 Jul, mxb wrote:
> ?? ?? ?? ??,  ??  .
> ??  ?? ?? ??.

Also fix your goddamn mail client. Your encoding is shit.



Re: tmpfs

2016-07-31 Thread Consus
On 19:54 Sun 31 Jul, mxb wrote:
> Who gives a sh*t?!
> Ppl supporting OpenBSD community what matters - with userbase without users is
> like masturbating.
> 
> Ppl like me test public diffs on live equipment, donate money and buy CDs so
> Theo can continue to milk this project
> so he can bike in Canadian woods.
> 
> As we speak it in Russia:
> “His long tongue will some day shorten his neck”.
> 
> Good advice for him is to pledge() his mouth before someone else do it.
> 
> The beauty in globalization is that distances and time get shorter.
> Even time-to-market AND market itself.
> 
> With his big mouth like THIS he might get it turbulent.
> He actually did, buy pulling off DARPA feed.

Come on, both you and Theo are such drama queens. Shut up already.



Re: Is OpenSMTPD worthy of OpenBSD inclusion?

2015-10-06 Thread Consus
On 18:47 Mon 05 Oct , Jason A. Donenfeld wrote:
> I maintain both distribution packages for it (Gentoo), as well as my
> entire infrastructure, which is based on OpenSMTPD. I've "bet the
> farm" on the project, so to speak.

Oh, so you were that guy who released "stable" ebuild without Berkeley
DB support? I vaguely remember I had to ask QA to fix it because you
ignored the bug report.