NextCloud: failed integrity checks

[Nicolas Schmidt]

After installation on OpenBSD 6.3 with pkg_add, NextCloud complains about files 
failing the integrity checks. More specifically:

- occ
 * expected hash: 
7e3fce0d7b5c20a7775ed1b548cb2e29bed078d3ca77b01a83d438f671b3d473147d4e8217d2084e17b6fe23a18ba258b11ba60106e23381f1e2889ce14971c4
 * current hash:  
7693eb89c0bc218712d68ec58599efa46e5c3729814e2aad16bf2c0079be7ae1909f072ead7889883c0a89b6c51570800d9e8a71f35866cb4e0c47aeaa5a4b2b

- version.php
 * expected hash: 
4e9046aca4fd8e942ba7bd505374e22ddd500a99b3a46d57d629b99c3132a66206883053f22801894929e51fca307c740062b497d55639bcc9a3154ada3504ff
 * current hash:  
30cd43589fc8ab273fa25e1a477c8cbadb13bac5541daa6d3fa0490a0c2054c2c29a274fd50eec66934a9d9adc541dec8701e7463922d36174478ae3e9a64981

- apps/updatenotification/appinfo/info.xml
 * expected hash: 
bf7983ffe422ba215c04a0069081fab0c78ba81fa40a90cbdd3595182e011fb7f3e0bd1cd14cdea742cafb89f1da001582fe8d560749d98ea540b4ee76dd9898
 * current hash:  
d2984fa816b4cea71e7c09f36a4132e7cb88d357f22e1c795778deccdb4066beaef2876b95d849e6eeae37b879c0f63500b0958a6a61bab1c933736bf135c440


Anybody able to reproduce?

--Nicolas

Re: Status of Owncloud?

[Nicolas Schmidt]

Thanks for the hint ax0n, I'll give NextCloud a try; after all, I wasn't 
entirely happy with Owncloud anyway, as I had issues uploading large files (100 
MB and bigger).

@Mischa: Your diagnosis was correct: I completely forgot that there is some 
extra work to be done to make PHP/cURL work in jailroot. Besides 
"/etc/resolv.conf", I also had to copy

/etc/ssl/cert.pem
/etc/services
/etc/php-5.6.ini

to /var/www/etc/ to make things work.

--Nicolas

> Am 22.07.2018 um 19:31 schrieb Mischa :
> 
> Besides that, in order to provide it an "internet" connection you need to 
> copy your resolv.conf to /var/www/etc/
> 
> Mischa
> 
> 
>> On 22 Jul 2018, at 19:26, Ax0n  wrote:
>> 
>> On Jul 22, 2018 10:11, "Nicolas Schmidt"  wrote:
>> 
>> Hi,
>> 
>> I just installed and configured owncloud on OpenBSD 6.3, and so far
>> everything seems to work (except for owncloud complaining about not having
>> an internet connection). However, when visiting http://localhost/owncloud/
>> after installation, I was greeted by an unfriendly message telling me that
>> owncloud doesn't run properly on OpenBSD. This message didn't go into more
>> details, nor could I find anything on owncloud.com or openbsd.org regarding
>> this.
>> 
>> So I'm wondering, what's the status of owncloud on OpenBSD? Is it still
>> supported? Are there plans to remove support for it in future releases?
>> 
>> Best,
>> Nicolas
>> 
>> 
>> I know this doesn't directly answer your question, but it seems like many
>> users (especially within but not limited to the OpenBSD community) started
>> preferring NextCloud ( https://nextcloud.com ) which appears to be
>> maintained by several of the original OwnCloud developers.
>> 
>> --ax0n

Status of Owncloud?

[Nicolas Schmidt]

Hi,

I just installed and configured owncloud on OpenBSD 6.3, and so far everything 
seems to work (except for owncloud complaining about not having an internet 
connection). However, when visiting http://localhost/owncloud/ after 
installation, I was greeted by an unfriendly message telling me that owncloud 
doesn't run properly on OpenBSD. This message didn't go into more details, nor 
could I find anything on owncloud.com or openbsd.org regarding this.

So I'm wondering, what's the status of owncloud on OpenBSD? Is it still 
supported? Are there plans to remove support for it in future releases?

Best,
Nicolas

segfault when exiting a program

[Nicolas Schmidt]

Hi,

a while ago I posted on this list because of a problem I experienced with 
building OpenBSD 6.2-current from source (the base system, not the kernel). 
Today I found the culprit, and it's rather strange: returning from main(), or 
calling exit() explicitly causes a segmentation fault.

A minimal example is:

int main(int argc, char **argv) { return 0; }

Evaluating cc -o test test.c; ./test should result in a segmentation fault. 
Here's the backtrace gdb gives me:

#0  _libc___cxa_finalize () at /usr/src/lib/libc/stdlib/atexit.c:133
#1  0x0de4d9fb in _libc_exit (status=0) at /usr/src/lib/libc/stdlib/exit.c:54
#2  0x18bef421 in main () from /home/nico/test

Anyone able to reproduce this?

Best,
Nicolas Schmidt

make_keys produces segfault when building 6.2-stable

[Nicolas Schmidt]

I just tried building the base in 6.2-stable (building the kernel worked fine), 
following the instructions in https://man.openbsd.org/release. Unfortunately, 
the build process fails when trying to build libcurses. The error I get is

./make_keys keys.list > init_keytry.h
Segmentation fault (core dumped)
*** Error 139 in lib/libcurses (Makefile:123 'init_keytry.h')
*** Error 1 in lib (:48 'all')
*** Error 1 in . (Makefile:90 'do-build')
*** Error 1 in /usr/src (Makefile:74 'build')

Manually running `cd /usr/obj/lib/libcurses && ./make_keys key.list` also 
produces a Segmentation fault. Any ideas what's going on here?

Best,
Nicolas

Re: Upgrade 6.1->6.2 fails with "id 0 on/: file system full"

[Nicolas Schmidt]

Thanks Tim, that was right on the money! Indeed my „/bsd“ was a symbolic link, 
pointing to „/bsd.mp“. Because the target path of the symlink was absolute, 
when it tried to write the new kernel to „./mnt/bsd“ it of course pointed to 
the ramdisk.

After removing that symlink, the upgrade process went through without a hitch.

TL;DR: Use relative paths when you symlink „/bsd“.

Nicolas

> Am 20.02.2018 um 15:42 schrieb trondd <tro...@kagu-tsuchi.com>:
> 
>> On Tue, February 20, 2018 8:34 am, Nicolas Schmidt wrote:
>> Hey,
>> 
>> it's me again, still trying to upgrade to 6.2.
>> 
>> After choosing to skip verification and continue the upgrade process, I
>> now immediately get the following error:
>> 
>>Installing bsd0% |
>>id 0 on /: file system full
>> 
>>/: write failed, file system full
>>ftp: Writing -: No space left on device
>> 
>> Going to a shell, "df" reveals
>> 
>>Filesystem512-blocksUsedAvailCapacityMounted on
>>/dev/rd0a  61436116   27100%/
>>/dev/sd2a   2057756179068  1775804  9%/mnt
>>.
>>.
>>.
>> 
>> To me it seems, the install script is trying to install the kernel on the
>> ram disk mounted on / instead of the actual root partition mounted on /mnt
>> (sd2 is the volume I chose for installation; it's a RAID 1). Since the ram
>> disk is full, this of course has to fail.
>> 
>> Any suggestions?
>> 
>> Best regards and thanks for your help,
>> Nicolas
>> 
> 
> This just came up on Daemonforums.  The user had a symlink pointing to an
> absolute path starting with /.  The installer follows that symlink to the
> ramdisk / instead of /mnt.
> 
> http://daemonforums.org/showthread.php?p=63885
> 
> Tim.

Upgrade 6.1->6.2 fails with "id 0 on/: file system full"

[Nicolas Schmidt]

Hey,

it's me again, still trying to upgrade to 6.2.

After choosing to skip verification and continue the upgrade process, I now 
immediately get the following error:

Installing bsd  0% |
id 0 on /: file system full

/: write failed, file system full
ftp: Writing -: No space left on device

Going to a shell, "df" reveals

Filesystem  512-blocks  UsedAvail   CapacityMounted on
/dev/rd0a 6143  6116   27   100%/
/dev/sd2a  2057756179068  1775804 9%/mnt
.
.
.

To me it seems, the install script is trying to install the kernel on the ram 
disk mounted on / instead of the actual root partition mounted on /mnt (sd2 is 
the volume I chose for installation; it's a RAID 1). Since the ram disk is 
full, this of course has to fail.

Any suggestions?

Best regards and thanks for your help,
Nicolas

Re: SHA256.sig not contained in install62.iso

[Nicolas Schmidt]

Sorry, I of course meant to say it‘s *not* on it.

> Am 20.02.2018 um 12:56 schrieb Nicolas Schmidt <schmi...@math.hu-berlin.de>:
> 
> Hi,
> 
> I am finally getting around to upgrading 6.1->6.2. When I try to install from 
> CD using the install62.iso image, the install script complains that it can't 
> find SHA256.sig (indeed, it's on it).
> 
> Is that supposed to happen?
> 
> Best,
> Nicolas A. Schmidt

SHA256.sig not contained in install62.iso

[Nicolas Schmidt]

Hi,

I am finally getting around to upgrading 6.1->6.2. When I try to install from 
CD using the install62.iso image, the install script complains that it can't 
find SHA256.sig (indeed, it's on it).

Is that supposed to happen?

Best,
Nicolas A. Schmidt

Re: Integrating "safe" languages into OpenBSD?

[Nicolas Schmidt]

> Am 04.12.2017 um 14:45 schrieb Nick Holland :
...
> 
> Oh yeah.
> I recently discovered a very major business operations application where
> rather than using the OS's FTP and SFTP functions, they wrote their own
> in "safe" Java.  I don't know why.
...
> If the other machine is being serviced?  Network broke?  receiving
> machine unable to recieve?  Oh well.  Magic doesn't work, the file is
> lost, without alerting the "sending" program.
> 
> Error reporting?  Well, for a long time, I thought it was non-existent,
> but I recently found they just dumped all the java runtime output to a
> file.  Nothing is actually done with this info in the application, but
> if 100+ lines of J-crap is your favorite way to see "server timeout",
> this is your tool.
...
> Nick.

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.

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.

Integrating "safe" languages into OpenBSD?

[Nicolas Schmidt]

Hi,

I recently watched a recording of Theo's talk on pledge at EuroBSDCon 2017, in 
which the question of memory-safe languages and their practical usefulness came 
up. Specifically, someone in the audience criticized the approach taken by 
OpenBSD, which (as I understand) accepts that all software is broken and 
mitigates the damage caused by various classes of exploits through techniques 
like ASLR, and suggested that instead one should stick to "memory safe 
languages" to avoid these exploits altogether.

As a response to this, Theo asked rhetorically "Where's ls, where's cat, 
where's grep, and where's sort?", implying that noone so far bothered to write 
implementations of even the basic unix utilities in such a language.

This brings me to the question, what if someone actually bothered? Under what 
conditions would you consider replacing one of the current C implementations 
with an implementation written in another, "safer" language? Note that with 
Cgrep and haskell-ls, there do in fact exist implementations/analogues of two 
of the mentioned utilities in a memory safe language (Haskell).

Best,
Nicolas Schmidt

Re: About WPA2 compromised protocol

[Nicolas Schmidt]

Can this issue even be fixed on the AP side? You could change the AP‘s 
behaviour to never ever resend Message 3, but that seems very drastic.

As far as I understood the article by Vanhoef and Piessens, the vulnerability 
lies within the behavior of the client (that conforms to the 802.11i 
amendment), as it still accepts retransmissions of Message 3 even if it is 
already in the PTK-DONE state.

—
Nicolas Schmidt

> Am 17.10.2017 um 19:15 schrieb Matthew Graybosch <li...@matthewgraybosch.com>:
> 
> On Tue, 17 Oct 2017 19:09:29 +0200
> "Stephane HUC \"PengouinBSD\"" <b...@stephane-huc.net> wrote:
> 
>> Just for the fun:
>> http://www.commitstrip.com/en/2017/10/16/wpa2-vulnerability-just-a-small-update/
> 
> I saw somebody share that on Mastodon this morning. :)
> 
> On a more serious note; am I correct in assuming that the patch is
> already in 6.2?
> 
> -- 
> Matthew Graybosch
> https://matthewgraybosch.com
> 
> "If you didn't want me to say 'both', you should have used XOR."

Re: permission denied local nfs mount

[Nicolas Schmidt]

Did you try setting an explicit netmask?

> Am 29.07.2017 um 01:36 schrieb Allan Streib :
> 
> 6.1 amd64 release
> 
> My goal is to serve files from a directory in my home dir via httpd. As
> I understand it the way to do this is a local NFS mount in the httpd
> chroot.
> 
> Basically following the FAQ for NFS I set up this:
> 
> $ cat /etc/exports
> /home/astreib/work/new-site.org -ro -network=127.0.0.1
> 
> $ showmount -e
> Exports list on localhost:
> /home/astreib/work/new-site.org127.0.0.1
> 
> $ doas mount -t nfs 127.0.0.1:/home/astreib/work/new-site.org 
> /var/www/htdocs/new-site
> mount_nfs: can't access /home/astreib/work/new-site.org: Permission denied
> 
> Everyhing works if I remove the "-network=" from /etc/exports, i.e.:
> 
> /home/astreib/work/new-site.org -ro 127.0.0.1
> 
> I don't really understand why?
> 
> Allan

Re: Can I use OpenBSD as a desktop system?

[Nicolas Schmidt]

>> On 06/09/17 15:39, SOUL_OF_ROOT 55 wrote:
>> Can I use OpenBSD as a desktop system?
> 
> You?  No, I doubt it.
...
> But, you are welcome, and invited
...
> Nick.

Nick, I don't think you were being either welcoming or inviting there.

To answer OP's question: Yes of course you can, and I did so in the past. The 
experience wasn't bad, although of course using any free Unix as a desktop 
system is guaranteed to deliver some pain at least (don't expect it to "just 
work").

Nicolas

kernel panic: ehci_device_clear_toggle

[Nicolas Schmidt]

Hi,

I just installed OpenBSD 6.1 and set up a CUPS server with a usb printer, and 
I'm experiencing kernel panics that seem usb related.
These kernel panics actually occured also on the old version of OpenBSD I 
upgraded from, but only very rarely (once every few months a most). Now I've 
had three panics in the course of a few hours. The irony is that one of the 
reasons for upgradings was this exact problem; I assumed it would have been 
fixed, as it was mentioned on this list already.

I would like to file a bug report, but I can't gather all the infos asked for 
https://www.openbsd.org/ddb.html, as the keyboard stops working after the 
kernel panic (probably because it's a usb keyboard). So, here's the output I 
can give you:

# panic: ehci_device_clear_toggle: queue active
Stopped at  Debugger+0x7:   leave
TID PID UID PRFLAGS PFLAGS  CPU COMMAND
*359035 78367   541 0x1002  0x8 1   usb
216484  46276   0   0x14000 0x200   0   reaper
Debugger(d0a08f55,f54ee848,d09d62e0,f54ee848,0) at Debugger+0x7
panic(d09d62e0,dbaed460,f54ee88c,d08a0895,0) at panic+0x71
ehci_device_clear_toggle(d5d8ff00,d5d8ff00,d5a02800,0,2) at 
ehci_device_clear_toggle+0x29
usbd_clear_endpoint_stall(d5d8ff00,d5d8ff00,0,f54ee8dc,400) at 
usbd_clear_endpoint_stall+0x20
ugen_do_write(d5aa,1,f54eee8c,1,f54eed10) at ugen_do_write+0x2a8
ugenwrite(3f01,f54eee8c,1,d0508d09,db91169c) at ugenwrite+0x4f
spec_write(f54eedb8,db7b2aa4,f54eee74,d03cd5e9,d0bf6ae0) at spec_write+0xa7
VOP_WRITE(dba0fccc,f54eee8c,1,dbaf2c00,17a8840) at VOP_WRITE+0x42
vn_write(db91169c,db91116b4,f54eee8c,dbaf2c00,d0bf6ae0) at vn_write+0x8a
dofilewritev(db7b2aa4,8,db91169c,f54eeef4,1) at dofilewritev+0x1c6
sys_write(db7b2aa4,f54eef5c,f54eef7c,0,200286) at sys_write+0x8f
syscall() at syscall+0x250
--- syscall (number -813756072) ---
0x6:



One piece of context: the uid 541 is the user _cups, under which cupsd runs.

Best,
Nicolas

Re: torrent downloads

[Nicolas Schmidt]

Many distros sport torrents: NetBSD, Debian, and Ubuntu to name some. Rationale 
behind this is simple: torrents download with ridiculous speed if they are 
popular enough.

Best,
Nicolas

> Am 27.04.2017 um 14:36 schrieb Markus Rosjat :
> 
> Hi,
> 
> I think it's kinda pointless to have a torrent for this. You got enough good 
> mirrors to download from anyway. And nowadays it's not a biggy to download a 
> iso or so of somewhat 200mb.
> 
> and yes I'm the proud owner of some awesome puffy shirts too (if someone is 
> concerned about the download part :-P )
> 
> regards
> 
> markus
> 
>> Am 27.04.2017 um 13:55 schrieb Thuban:
>> Hello,
>> I was wondering if there is any particular reason explaining why there
>> is no torrent file to retrieve OpenBSD *.fs and *.iso.
>> 
>> I've been looking on the list and only found this site that doesn't
>> seems up to date [1].
>> 
>> If the reason is a lack of human ressources, I think I can handle it.
>> 
>> Regards.
>> 
>> [1] : http://openbsd.somedomain.net/
>> 
> 
> -- 
> Markus Rosjatfon: +49 351 8107223mail: ros...@ghweb.de
> 
> G+H Webservice GbR Gorzolla, Herrmann
> Königsbrücker Str. 70, 01099 Dresden
> 
> http://www.ghweb.de
> fon: +49 351 8107220   fax: +49 351 8107227
> 
> Bitte prüfen Sie, ob diese Mail wirklich ausgedruckt werden muss! Before you 
> print it, think about your responsibility and commitment to the ENVIRONMENT

Re: IPPORT_RESERVED 'security' check in nfsd obsolete?

[Nicolas Schmidt]

Am 19.01.2017 um 12:21 schrieb Theo de Raadt :

>> Then may I suggest to add an option to disable this behaviour for specific
mounts
>> ounts?
>
> No.
>
> NFS always required reserved ports.

Do you mean that the "reserved ports restriction" is required as part of the
NFS protocol spec? I took a look at https://tools.ietf.org/html/rfc7530 , but
couldn't find anyhing related to that.

Re: IPPORT_RESERVED 'security' check in nfsd obsolete?

[Nicolas Schmidt]

> Am 19.01.2017 um 01:20 schrieb Theo de Raadt :
>
> No, this change will not be done.

Then may I suggest to add an option to disable this behaviour for specific
mounts? NetBSD provides the "-noresvport" flag for this. The following quote
is from the NetBSD man for exports:

"The -noresvport option specifies that NFS RPC calls for the filesystem do
not have to come from reserved ports. Normally, clients are required to use
reserved ports for operations. Using this option decreases the security of
your system."

IPPORT_RESERVED 'security' check in nfsd obsolete?

[Nicolas Schmidt]

Hello everyone,


I'd like to make a suggestion regarding NFS in OpenBSD; let me apologize in
advance if this isn't the right place to make this suggestion.

Currently (at least on 5.8, I haven't upgraded yet), the nfs daemon refuses to
accept a mount request if it comes from a non-privileged port (>=
IPPORT_RESERVED). As I understand, this was once a 'security feature' in the
time of mainframes, when access to computer was restricted. In any case, I
believe this behaviour should be changed as it does not provide security, and
also leads to problems: for example, it means one has to use the markably
slower SMB protocol when using an OpenBSD server as a remote mount on a FireTV
stick (my use case).

I therefore propose to remove this source port check from the nfs code, or
alternatively, to add an option to export nfs volumes without this check. The
first thing can e.g. be accomplished by modifying the OpenBSD source in two
places, as follows (patches for 5.8):

patch /usr/src/sbin/mountd/mountd.c < mountd.patch
patch /usr/src/sys/nfs/nfs_subs.c < nfs_subs.patch

where

### start of mountd.patch ###
369c369
<   if (sport >= IPPORT_RESERVED) {
---
>   if (0 == 1) { // don't fail when sport >= IPPORT_RESERVED
467c467
<   if (sport >= IPPORT_RESERVED) {
---
>   if (0 == 1) { //don't fail when sport >= IPPORT_RESERVED
483c483
<   if (sport >= IPPORT_RESERVED) {
---
>   if (0 == 1) { //don't fail when sport >= IPPORT_RESERVED
### end of mountd.patch ###


### start of nfs_subs.patch ###
1455c1455
<   (ntohs(saddr->sin_port) >= IPPORT_RESERVED ||
---
>   (0 == 1 || // don't fail when sport >= IPPORT_RESERVED
### end of nfs_subs.patch ###


Best,
Nicolas Schmidt