Re: yubikey OTP, xlock(1) and /var/db/yubikey/`user`.ctr permissions
On 12/06/12 00:22, Alexander Hall wrote: On 12/02/12 14:31, Andreas Bartelt wrote: Hello, I've set up yubikey OTP authentication and also want to use it for xlock(1) authentication. /var/db/yubikey has permissions 770 for root:auth. In case no `user`.ctr file exists in /var/db/yubikey at first login via yubikey, it is created automatically with permissions 644. This fails in case of xlock(1) authentication via yubikey: [from /var/log/authlog] yubikey: user test: fopen: /var/db/yubikey/test.ctr: Permission denied Changing `user`.ctr permissions to 660 for root:auth makes it work. Should 660 be the default permissions for `user`.ctr? Yeah, that makes sense. I remember having issues with xlock myself but I didn't investigate it enough it seems. Does the diff below fix your issues? yes, permissions for `user`.crt are set correctly now. Thanks, Andreas
Re: Problem building -current userland
On Tue, 4 Dec 2012, Dave Anderson wrote: Problem solved; PEBCAK. I didn't fully understand what 'cvs update' was doing, and managed to create a source tree containing a mixture of old and current files. Apologies for the noise. Dave I recently upgraded to the 2 December 2012 amd64 snapshot, then at about 11am EST today (4 December) updated my source tree to -current. After compiling and installing a new kernel and rebooting, my attempt to rebuild userland aborted with a slew of errors in /usr/src/usr.sbin/smtpd/smtpd/../dns.c. In case this was a short-term glitch I re-updated my source tree at about 4pm EST and tried again, with the same result. Is this a known problem, or have I managed to screw something up? I'm using the same build procedure as I've successfully used before, and didn't see anything in the current version of the 'building from source' section of the FAQ that would require changing it or see anything relevant in 'following current'. The sequence of commands I used is: cd /usr/src cvs -z 9 -d$CVSROOT -q up -Pd cd /usr/src/sys/arch/`machine`/conf config GENERIC.MP cd ../compile/GENERIC.MP make clean make make install reboot cd /usr/obj touch junk mkdir -p .old mv * .old rm -rf .old cd /usr/src make obj cd /usr/src/etc env DESTDIR=/ make distrib-dirs cd /usr/src make build Thanks for any help, Dave -- Dave Anderson d...@daveanderson.com
Re: BSD licensed gnupg replacement question
I said I can't code that. I know that gnupg is in the ports tree, but it just seems strange to me that it isn't on the base system, because for me it sounds logical that if one of the key points of openbsd is cryptography, it would have a bsd tool like gnupg. The netpgp thing looks very cool, I didn't know about it. So my question is why there isn't a tool like that on base, I'm asking out of curiosity, maybe some historical, reason, technical... I'm not trying to point this as a fault, I just want to understand better the fact that gnupg or a bsd licensed equivalent isn't in the base system. El jueves, 6 de diciembre de 2012, Martin Schröder escribió: 2012/12/6 Maximo Pech mak...@gmail.com javascript:;: I'd like to know your thoughts about this. Shut up and show us your code.
tmux separate pane characters
Hi misc@, I have an issue with some fonts when using tmux, as they don't display the separate characters between panes. Are there any -a option as in mc or 'ascii_chars=' as in mutt? Thank you.
Re: BSD licensed gnupg replacement question
On Thu, Dec 06, 2012 at 13:10, Maximo Pech wrote: It's incredible for me that OpenBSD, an operating system that claims to have integrated cryptography (yes I know that the cryptography is on the core OS layers) doesn't have in the base system a tool like gnupg, and even more incredible, that there isn't a single production ready, gnupg-like, BSD licensed tool out there (I don't have the skills and time to program one myself). I'd like to know your thoughts about this. openssl can do pgp like things.
Re: BSD licensed gnupg replacement question
Maximo Pech [mak...@gmail.com] wrote: I said I can't code that. If you already knew the answer was write it, then you asked the wrong question. I know that gnupg is in the ports tree, but it just seems strange to me that it isn't on the base system, because for me it sounds logical that if one of the key points of openbsd is cryptography, it would have a bsd tool like gnupg. The netpgp thing looks very cool, I didn't know about it. Do you have any idea how abusrd this is? So my question is why there isn't a tool like that on base, I'm asking out of curiosity, maybe some historical, reason, technical... I'm not trying to point this as a fault, I just want to understand better the fact that gnupg or a bsd licensed equivalent isn't in the base system. The original PGP program was mostly public domain. As time went on, it went to a highly restrictive license. GnuPG, and later, NetPGP represent the people who had desires to fix that problem. If you want to do it again, nobody will stop you. OpenSSH and OpenBSD IPsec represent the OpenBSD solutions to the quality and licensing problems in those areas. OpenSSH is still the gold standard, OCF/IPsec, maybe not. PGP worked, was public domain, encrypts files, and solved one problem. Network layer encryption is an entirely different, and for many, a much more important problem.
Re: qemu -nographic
On 11 January 2011 11:18, a.velichin...@gmail.com wrote: The trick with /etc/boot.conf does work; this should transform the cd48.iso install cd into a 'serial' one: $ echo 'set tty com0' /tmp/boot.conf $ growisofs -M cd48.iso -l -graft-points /etc/boot.conf=/tmp/boot.conf Then: $ qemu -nographic -cdrom cd48.iso OpenBSD/i386 CDBOOT 3.15 boot booting cd0a:/4.8/i386/bsd.rd: 5900404 I've tried this on a Linux, and it worked for getting OpenBSD installer to boot through a serial console. However, I was using install52.iso, which includes the filesets, and I was not able to install any filesets from a CD that was altered by growisofs on Linux as above. Looking at /mnt2 during the install, I've noticed that all filenames were in CAPS, and /mnt2/TRANS.TBL was missing (however, all appropriate /mnt2/*/TRANS.TBL and /mnt2/*/*/TRANS.TBL were still present and correct). I worked around by adding the original CD as a regular drive, and selecting disk and wd0 for installing the filesets. The ISO filesystem was mounted from wd0 automatically and with no problems or hoops. apt-get install dvd+rw-tools echo 'set tty com0' boot.conf cp -p install52.iso install52.iso.origFromFTP growisofs -M install52.iso -l -graft-points /etc/boot.conf=boot.conf kvm -m 6144 -smp 4 -drive file=/dev/sda,if=scsi \ -drive file=/dev/sdb,if=scsi -drive file=/dev/sdc,if=scsi \ -drive file=install52.iso.origFromFTP -cdrom install52.iso -boot d -nographic `dpkg --list` : ii dvd+rw-tools 7.1-6DVD+-RW/R tools ii qemu-kvm 0.12.5+dfsg-5+squeeze9 Full virtualization on x86 hardware Also, the version of qemu as above has another useful option that allows you to bypass VNC and X -- -curses. Apparently, you must either choose -nographic and enable serial on the media, or choose -curses and have VGA emulation with no usable log of the session. It'd be nice to have -nographic work with VGA emulation, too, and not be a serial-only option. C.
Re: tmux separate pane characters
On 7 December 2012 17:19, Daniel Bolgheroni dan...@bolgh.eng.br wrote: Hi misc@, I have an issue with some fonts when using tmux, as they don't display the separate characters between panes. Are there any -a option as in mc or 'ascii_chars=' as in mutt? No -- the fallback is to use the ASCII equivalents when ACS cannot be used. -- Thomas Adam