Panic using tmpfs on current
So, I know this may be the wrong mailing list, well, it is, but I'm a first time user and I don't think I have enough information to open a bug report. I am trying openbsd 5.5 (current) on an smp amd64 machine. after some late-night experimentations with systrace, I decided that, for untrusted applications, it would be better to have a separate user (let's say temp1). I added, on /etc/rc.local mount_tmpfs -u temp1 -g temp1 -s 8G tmpfs /home/temp1 to recreate the home directory of the user at every startup. I could have done it via fstab, I know. The machine has 16G of ram installed. I was watching a long (1h+) video with minitube, so data may have been written to /home/temp1, and I had a kernel panic. trace: panic() at panic+0xee amap_wipeout() at amap_wipeout+0xf0 uvm_unmap_detach() at uvm_unmap_detach+0x90 sys_munmap() at sys_munmap+0x120 syscall() at syscall+0x24f end trace frame: 0x832e23dc0, count: 0 show map: MAP 0x81345da5: [0x71880c70a74-0x1c28348] brk() allocate range: 0xc3c9df7540fa8348-0x90669066 stack allocate range: 0x53e589485590-0x48b486508ec8348 sz=1216454588, ref=838853055, version=2685829333, flags=0x48b48d2 show page: PAGE 0x81345da5: flags=40fa8348CLEAN,FAKE,ZERO,FREE,ACTIVE,ENCRYPT,PMAP0, vers=-1010180235, wire_count=-1872337306, pa=0x53e589485590 uobject=0x71880c70a74, uanon=0xc0854881a01680d5, offset=0xc28348 loan_count=-1872337306 [page ownership tracking disabled] wm_page_md 0x81345e0d I also had show mount, show vnode and registers, but apparently output is truncated... I'm not sure about the cause, but after the panic, every time I ran firefox X froze, I couldn't switch back to a tty and had to perform a hard reset. now I unmounted the tmpfs over /home/temp1 and so far, I had no trouble. I did run tmpfs without problems for some time, without specifiying -s 8G and -u temp1 -g temp1.
Is [binary] package signing planned?
Hi. I'm seeing, in this mailing list, much talk about the datagate and related matters, and I can see why the topic may be of interest to many OpenBSD users. Anyway, I really like OpenBSD, but I always restrain myself from using it on a desktop machine for a single reason: while pkg_add supports signed packages, those provided by the OpenBSD project aren't. You can easily find other similar complaints on the internet... but I really fail to understand why the project isn't providing signed packages, when there is already support for it. Why do signed packages matter? Well, I can fetch the ports tree in a secure way, verify its integrity and origin, and then ports definitions contain source packages hashes. I like the idea and the flexibility, but on desktop computers, it may be undesirable to compile software, especially big suites like X, Gnome, Firefox, LibreOffice. This gets even worse when the desktop is a laptop computer, like in my case. I won't use unsigned packages, because there's a concrete risk of corruption, I don't know if I should trust the mirror, and even with the official OpenBSD mirrors... it's easy, really easy, for someone to run an http/ftp MITM on me and give me a backdoored, or trojaned, binary package. Not only on a free WiFi, on a hotel, abroad, but even using a secure connection, it's easy for the isp, or the government, to just give me a bad bash package, and gain root in a clap of hands. Then, the datagate revealed how it's easy to modify stream in between: if there are people capable of intercepting someone request to linkedin on a rogue router in the path, and immediately give back a page that contains a browser exploit, before the real site can produce a response, how it's easy to intercept, say, a pkg_add update to an openbsd mirror and give back a backdoored package? I'm not talking only about the five eyes, any government, even private entities, are capable of this. That's the reason why almost all gnu/linux distributions sign packages. Even other *BSD distributions are starting to adopt signed binary packages: pkg(ng), on freebsd, checks that the repository signature is made with the right key. It calculates the public key's hash, and confronts it with the hash present in /usr/share/keys/pkg/trusted/. The repository definition contains a list of packages' hashes, which is the signed part. Every package provides a signature of all files provided. TL;DR: pkgng is totally signed. and pkg_add, as I already stated, while it doesn't have the concept of a repository, still supports individually signed packages. What is holding the OpenBSD project from implementing signed binary packages, and, is it planned?
Re: Is [binary] package signing planned?
Thanks. I tried 5.5 on my laptop and as I said, it works, even better than freebsd 10, despite being a beta. I will switch to openbsd with the release. The only other problem is that I have external/ultrabay hdds that use lvm2, and I'll have to migrate the data, I think. Anyway, while it's fine to only warn the user in case of an invalid signature, it would be nice to somehow inform him of the fact that packages are signed, are being verified (outside of the man page), and that they passed signature checks, like, for example, yum does. After all, https informs the user of its use, via the extra S, a lock, a green bar. SSH is implicitly secure, and exposes the server's fingerprint. Not providing positive feedback might trick the user into thinking that packages are being installed securely while working with old or misconfigured systems Il martedì 4 febbraio 2014, Marc Espie es...@nerim.net ha scritto: 2014-02-04 Kim Twain kimtwa...@gmail.com javascript:;: Does pkg_add automatically check these signatures, or, as of now, I'd need to manually download the packages, verify them with signify and then install them locally with pkg_add? In -current, if you don't use any flags to pkg_add, and you don't see any message at the end, the packages were signed and verified. (and by default, post 5.5, pkg_add will probably error out if the packages are not signed if you don't use -Dunsigned !) Maybe you're already using signed packages and haven't noticed. (there were two or hiccups in some snapshots, but apart from that, things have been working great). Getting a streamlined process WAS the difficult part in getting signed packages out, NOT the technical feat of having signed packages... After all, pkg_create/pkg_add has known how to sign stuff for 3 years by now. signify(1) makes things more transparent: no chain of trust, pure keys. One cool thing is that the signatures are small enough that they can be embedded directly in the package (which already has sha256 for everything). This has the advantage of decentralization: package snapshots can be partially synchronized, and still each package carries its own signature. Less margin for strange errors - stuff that works most of the time - more trustworthy. Remember that message about ssh keys that changed that you used to get when admins weren't savvy about getting keys around, or all those self-signed https certificates you've been trained to ignore ? signatures are the same. if they're not 100% present by default, people will be trained to ignore them. If you think security is a technicality, you only have 1/3rd of the story.Getting the process right and making sure the users don't do anything stupid is the right part.
