Re: ifconfig scan while connected
On Sun, Sep 7, 2014 at 5:56 PM, Fabian Raetz fabian.ra...@gmail.com wrote: On Sun, Sep 07, 2014 at 02:11:04PM +0200, Mike Burns wrote: A `sudo ifconfig iwn0 scan' works but only if the device is disconnected. Is this expected behavior? Is this specific to my card? Am I interpreting the results correctly? Hi, this is a known problem with the iwn(4) driver. I'm in the process of backporting a patch from FreeBSD, which seems to fix the problem. Running here with this patch for an hour or so and can scan with iwn running and it continues to work. I'll probably send a patch to tech@ next week. I'm also interested in this. ciao! David
Re: provide public gpg key(s) by the install-isos
On 07-09-2014 16:12, Elmar Stellnberger wrote: If I purchase a set of OpenBSD CDs or if I download them via http or ftp then I am in need of verifying my CDs/images. If the NSA regularly intercepts laptop shipment so it may do with the shipment of OpenBSD CDs. Now; how to obtain an authentic copy of your public key? Buy a CD set or download the install.iso from a mirror, and then download the SHA256 from many places using different isp's/vpn/tor. After that use signify to check things. This is your best bet at this moment. There is likely no better solution than buying an OpenBSD or Linux DVD with a magazine at the next newspaper kiosk as such a purchase will be 100% anonymous with regards to the actual copy of the magazine you select: it will be impossible to alter the magazine just for a specific user and altering all the copies of a magazine would be discovered quickly. Yes, this would be a solution. But who would pay the magazine to put the key there? There may be other solutions of obtaining an authentic copy of your projects public key like DNSSEC/DANE; nonetheless the one proposed in here is for sure the most simple and straight forward one: DNSSEC has been discussed many times on this list, it will simply not be implemented. And, with signify, if you can be 99.99% sure that you got a release right, then the next ones you'll get 99.% right, because the keys for the upcoming release are on the current one. And this will keep going for the foreseeable future. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
Re: provide public gpg key(s) by the install-isos
On Mon, Sep 8, 2014 at 4:12 AM, Elmar Stellnberger estel...@gmail.com wrote: [...] P.S.: URL about NSA regularely intercepting laptop shipments: http://www.extremetech.com/computing/173721-the-nsa-regularly-intercepts-laptop-shipments-to-implant-malware-report-says Consider this -- How much is the NSA or some other similar organization going to pay to run a man-in-the-middle on you? How much would it cost them to intercept, not just the CD being shipped, but also your queries on random mirrors? (Not asking whether you consider yourself valuable enough to them that they would intercept your next hardware purchase, but you should ask yourself whether you really are that valuable to them.) I posted a bit of meandering on the subject recently which you might find interesting, Giancarlo's post to this thread makes for a lot quicker read. I think he oversimplifies the numbers, and I don't agree that the numbers improve with age -- there are balancing factors and one factor is exactly the value to them in targeting the individual in question, but I agree with his general message. It is worth checking the checksums from various sources, maybe at different times, from different machines, on different networks. How far you need to go, and how you devise your out-of-band checks is something you have to figure out. And do get the CDs. If they are intercepted and you check the checksums like you should, you have a good chance of finding out that you are targeted. -- Joel Rees Be careful where you see conspiracy. Look first in your own heart, and ask yourself if you are not your own worst enemy.
Re: provide public gpg key(s) by the install-isos
On Tue, 9 Sep 2014, at 12:46 AM, Joel Rees wrote: On Mon, Sep 8, 2014 at 4:12 AM, Elmar Stellnberger estel...@gmail.com wrote: [...] P.S.: URL about NSA regularely intercepting laptop shipments: http://www.extremetech.com/computing/173721-the-nsa-regularly-intercepts-laptop-shipments-to-implant-malware-report-says Consider this -- How much is the NSA or some other similar organization going to pay to run a man-in-the-middle on you? How much would it cost them to intercept, not just the CD being shipped, but also your queries on random mirrors? [...] The keys have also been posted to the mailing list at least once (look for a post by Theo in the thread a half-baked analysis of the verification chicken-and-egg problem, and request). The mailing list is mirrored by many different services (such as marc), so also comparing the keys against the various mailing list mirrors would create additional complexity for any organisation trying to MITM the keys you receive. -- Carlin
firefox crashes very often on amd64 5.5
Hello, firefox-26.0p1 craches very oftern (once per hour) on amd64 OpenBSD 5.5. Is this a known problem? --Carsten
Re: firefox crashes very often on amd64 5.5
Bump you rlimits or provide more information.
Re: Recording from azalia does not work
On Tue, Jun 26, 2012 at 09:16:38AM +0200, Alexandre Ratchov wrote:
On Mon, Jun 25, 2012 at 10:53:34AM +0200, Gregor Best wrote:
I'm trying to get recording from the mic input of my laptop working, but
have
not have success so far. I'm using a thinkpad laptop
with an azalia device and a pretty run of the mill headset, attached to
headphone out and microphone in. The headset itself works
fine on other machines and the microphone input and headphone output of the
laptop work fine hardware-wise (i.e. tested with another
operating system). On OpenBSD however, the mic input remains silent. Files
recorded with aucat -o foo.wav remain silent for the
entire recording duration, as if the mic was somehow muted.
Same here. My azalia connected mic works under OSX but not under
OpenBSD. Did you ever figure out a solution?
Below is the
output of mixerctl:
outputs.spkr_source=dac-0:1
outputs.spkr_mute=on
outputs.spkr=125,125
outputs.spkr_eapd=on
outputs.hp_source=dac-0:1
outputs.hp_mute=off
outputs.hp=155,155
outputs.hp_dir=output
outputs.hp_boost=off
outputs.mic_dir=input-vr80
inputs.beep_mute=off
inputs.beep=108
inputs.mix_source=dac-0:1,mic,hp
inputs.mix_dac-0:1=125,125
inputs.mix_mic=215,215
inputs.mix_hp=125,125
record.adc-0:1_source=mic
record.adc-0:1_mute=off
record.adc-0:1=253,253
outputs.hp_sense=plugged
outputs.mic_sense=plugged
outputs.spkr_muters=hp
outputs.master=157,157
outputs.master.mute=off
outputs.master.slaves=spkr,hp
record.volume=255,255
record.volume.mute=off
record.volume.slaves=adc-0:1
I have a similar problem. I've got a Macbook Air 5.1 running OpenBSD
5.5-stable. The microphone seems to be there, but I'm not able to get it
to record anything (aucat -o produces a silent file). The speakers and
headset work fine. Also, I noticed that Gnome 3 sound settings list no
input devices.
$ dmesg | grep azalia
azalia0 at pci0 dev 27 function 0 Intel 7 Series HD Audio rev 0x04: msi
azalia0: codecs: Cirrus Logic CS4206, Intel/0x2806, using Cirrus Logic CS4206
audio0 at azalia0
$ mixerctl -v
inputs.dac-0:1_mute=off [ off on ]
inputs.dac-0:1=86,86
inputs.dac-2:3_mute=on [ off on ]
inputs.dac-2:3=62,62
record.adc-0:1_source=mic [ mic ]
record.adc-0:1_mute=off [ off on ]
record.adc-0:1=124,124
outputs.hp_source=dac-0:1 [ dac-0:1 ]
outputs.hp_boost=off [ off on ]
outputs.spkr_source=dac-2:3 [ dac-2:3 ]
inputs.mic=85,85
outputs.mic_dir=input-vr80 [ none input input-vr0 input-vr50 input-vr80 ]
outputs.hp_sense=plugged [ unplugged plugged ]
outputs.spkr_muters=hp { hp }
outputs.master=86,86
outputs.master.mute=off [ off on ]
outputs.master.slaves=dac-0:1,dac-2:3 { dac-0:1 dac-2:3 }
record.volume=124,124
record.volume.mute=off [ off on ]
record.volume.slaves=adc-0:1 { adc-0:1 mic }
this seems correct at first glance; could you see whether the
recorded file is full of silence (zeros) or noise (numbers close to
zero)?
aucat -o /tmp/foo
and then:
hexdump /tmp/foo |less
noise would mean that there's a level knob to crank, while zeros
would suggest that something in the recording chain is disabled.
Here's the first page of output:
000495246465b38000e415745566d662074
010002800010002bb80ee000002
02000040010
03030804ae161646174
0405b00000e
050
060
070
080
090
0a0
0b0
0c0
0d0
0e0
0f0
100
110
120
130
140
150
160
As you can see, all recording
Re: provide public gpg key(s) by the install-isos
On 08-09-2014 09:46, Joel Rees wrote: I posted a bit of meandering on the subject recently which you might find interesting, Giancarlo's post to this thread makes for a lot quicker read. I think he oversimplifies the numbers, and I don't agree that the numbers improve with age -- there are balancing factors and one factor is exactly the value to them in targeting the individual in question, but I agree with his general message. If you are targeted by a governmental agency, not just NSA, it is pretty much game over for you. Unless you toss all you electronic devices and go live in the woods. As for the numbers, I just used them to make a point that if you got a release right, the probability of getting the next right increases. There are some other things you could do to get the keys. Ask someone to access a mirror and talk it to you over the phone. Even a sms message could do. If you're being targeted, there would be a lot of effort in subverting all these side channels and you eventually will discover that you're being targeted. Joel, I believe we all are targeted. I'm do not live in US so all my communications are being intercepted by the dragnet. Even people on US are being targeted. This isn't a paranoid's concern anymore. We should do what we can to at least achieve some privacy. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
Re: provide public gpg key(s) by the install-isos
On Tue, Sep 09, 2014 at 02:23:39AM +1200, Carlin Bingham wrote: The keys have also been posted to the mailing list at least once (look for a post by Theo in the thread a half-baked analysis of the verification chicken-and-egg problem, and request). The mailing list is mirrored by many different services (such as marc), so also comparing the keys against the various mailing list mirrors would create additional complexity for any organisation trying to MITM the keys you receive. Indeed. And don't forget keys posted on websites available over TLS, as well as the OpenBSD website, which is available via CVS over SSH. So there are existing, authenticated methods for verifying signify pubkeys. https://twitter.com/tedunangst/status/439308681176686592 https://github.com/libressl/libressl/blob/master/src/etc/signify/openbsd-55-base.pub untrusted comment: openbsd 5.5 base public key RWRGy8gxk9N9314J0gh9U02lA7s8i6ITajJiNgxQOndvXvM5ZPX+nQ9h Nicolai
Re: provide public gpg key(s) by the install-isos
On 08-09-2014 16:03, Nicolai wrote: And don't forget keys posted on websites available over TLS, as well as the OpenBSD website, which is available via CVS over SSH. So there are existing, authenticated methods for verifying signify pubkeys. The ssh fingerprints are only available on a non ssl web page. There are SSHFP records for this. But with no DNSSEC you incur on the same issue, of having to access the anoncvs page from many places/proxies/tor/etc to see if the ssh fingerprint match. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
Re: provide public gpg key(s) by the install-isos
I welcome your provision of the signify tool. What I still do not know is where on install55.iso I can find the pubkey and the sigfile for verifying the iso by itself (test run) as well as further isos (many Linux distros use the root directory for these files). You did not 'forget' to ship these files, did you? I just please you to put sth. like a README there to make new or low-brow users know which tool to use i.e. signify and where to find the pubkey and signing data and the session length. The session length is the third important parameter to know when verifying already burnt .isos because they tend to be zero padded at the tail (disregarding this fact will usually make the verification fail). What I know up to know is that I can boot into the CD-shell, mount cd0a, unpack base55.tgz and the *.pub files in ./etc/signify. However then when it comes to verify cd0a signify does neither accept input from /dev/cd0a nor from /dev/stdin. Additionally I can still not find the .sig file for the CD. To my mind it would also be a nice idea to have the session length i.e. 232294400 for install55.iso of 5.5 somewhere. The rest can be tested by dd and od to be zeroes.
Re: provide public gpg key(s) by the install-isos
Am 08.09.14 12:25, schrieb Giancarlo Razzolini: On 07-09-2014 16:12, Elmar Stellnberger wrote: If I purchase a set of OpenBSD CDs or if I download them via http or ftp then I am in need of verifying my CDs/images. If the NSA regularly intercepts laptop shipment so it may do with the shipment of OpenBSD CDs. Now; how to obtain an authentic copy of your public key? Buy a CD set or download the install.iso from a mirror, and then download the SHA256 from many places using different isp's/vpn/tor. After that use signify to check things. This is your best bet at this moment. There is likely no better solution than buying an OpenBSD or Linux DVD with a magazine at the next newspaper kiosk as such a purchase will be 100% anonymous with regards to the actual copy of the magazine you select: it will be impossible to alter the magazine just for a specific user and altering all the copies of a magazine would be discovered quickly. Yes, this would be a solution. But who would pay the magazine to put the key there? I had just bought such a magzine which shipped install55.iso as a whole. If the keys would have been in the root directory of that .iso then: Hooray! Sometimes they also ship the 'system rescue CD' as a whole; look at my proposal here: http://www.sysresccd.org/forums/viewtopic.php?f=6t=5208 There may be other solutions of obtaining an authentic copy of your projects public key like DNSSEC/DANE; nonetheless the one proposed in here is for sure the most simple and straight forward one: DNSSEC has been discussed many times on this list, it will simply not be implemented. And, with signify, if you can be 99.99% sure that you got a release right, then the next ones you'll get 99.% right, because the keys for the upcoming release are on the current one. And this will keep going for the foreseeable future. I welcome your provision of the signify tool. What I still do not know is where on install55.iso I can find the pubkey and the sigfile for verifying the iso by itself (test run) as well as further isos (many Linux distros use the root directory for these files). You did not 'forget' to ship these files, did you? I just please you to put sth. like a README there to make new or low-brow users know which tool to use i.e. signify and where to find the pubkey and signing data and the session length. The session length is the third important parameter to know when verifying already burnt .isos because they tend to be zero padded at the tail (disregarding this fact will usually make the verification fail). Cheers, By the way, do you have any good reason to distrust gpg? Cheers, Elmar
Re: provide public gpg key(s) by the install-isos
On Mon, Sep 08, 2014 at 10:11:52PM +0200, Elmar Stellnberger wrote: | I had just bought such a magzine which shipped install55.iso as a whole. | If the keys would have been in the root directory of that .iso then: Hooray! | Sometimes they also ship the 'system rescue CD' as a whole; look at my | proposal here: | http://www.sysresccd.org/forums/viewtopic.php?f=6t=5208 Trusting install55.iso on some magazine's CD is akin to trusting someone you don't know who claims he's not a fraud. Shall I prepare a nice magazine for you, with an install55.iso on the CD and proper signify pubkeys in that ISO image? What on earth are you going to do with the pubkeys you get in install55.iso? OK, now I take them out of the ISO and put them next to the image in the same directory on the CD. Nothing changes. Now I'll provide you with a system rescue CD as you proposed with the public keys of all major distros. Even including the signify pubkeys that will verify the proper keys were used to sign (my special edition) of install55.iso. | I welcome your provision of the signify tool. What I still do not know is | where on install55.iso I can find the pubkey and the sigfile for verifying | the iso by itself (test run) as well as further isos (many Linux distros use | the root directory for these files). You did not 'forget' to ship these | files, did you? No, they weren't put on the image because it doesn't make sense to put them there. You need to verify the image via alternative routes. Call up ten friends in ten different countries and ask them to all download the SHA256.sig file from their local mirror and compare them all verbally with what you download yourself. And you still won't be 100% sure. Add 20 more friends from 20 new countries. Even more. | I just please you to put sth. like a README there to make new | or low-brow users know which tool to use i.e. signify and where to find | the pubkey and signing data and the session length. The session length | is the third important parameter to know when verifying already burnt | .isos because they tend to be zero padded at the tail (disregarding this | fact will usually make the verification fail). If you didn't burn the iso yourself, why are you installing from it? | Cheers, | | By the way, do you have any good reason to distrust gpg? Apart from 'distrust', policy dictates it cannot be added to the base operating system unless as a last recourse[1] and, in fact: Replacement [of GPL-licensed code] by equivalent, more freely licensed tools is a long-term desideratum. [2] Guess what - signify is that equivalent, more freely licensed tool. It may not be feature-complete compared to GPG, but it provides the basic feature of verifying checksums you suggest to use GPG for (if you the added features of GPG in your OpenBSD system, it's a simple pkg_add(1) away). Cheers, Paul 'WEiRD' de Weerd [1]: http://www.openbsd.org/goals.html [2]: http://www.openbsd.org/policy.html -- [++-]+++.+++[---].+++[+ +++-].++[-]+.--.[-] http://www.weirdnet.nl/
Re: provide public gpg key(s) by the install-isos
On Mon, Sep 08, 2014 at 05:21:09PM -0300, Giancarlo Razzolini wrote: The ssh fingerprints are only available on a non ssl web page. Lots of people use CVS over SSH to update their systems, and thus already have fingerprints saved in their known_hosts file. In addition to checking multiple TLS-protected sites, which I previously mentioned, this is about as good as it gets. One can't ask for more. But with no DNSSEC you incur on the same issue, of having to access the anoncvs page from many places/proxies/tor/etc to see if the ssh fingerprint match. This thread is about verifying signify pubkeys, not DNSSEC. DNSSEC is an unencrypted protocol that relies on RSA-1024 and governments. It's horribly complex, and I can't tell if it's a make-work program (incompetent) or Project Bullrun (malicious). Maybe both, which is why the US govt likes it so much. Anyway, in my previous post I shared several good methods for verifying the 5.5 base key, as well as the key itself, and any one of the thousands of people on this mailing list can pipe up to say, That's not the key I have! That could be a hugely compelling and important moment -- and if it happens then perhaps there's more to say on the issue. Nicolai
Re: provide public gpg key(s) by the install-isos
On 2014-09-08, Giancarlo Razzolini grazzol...@gmail.com wrote: The ssh fingerprints are only available on a non ssl web page. There are SSHFP records for this. But with no DNSSEC you incur on the same issue, of having to access the anoncvs page from many places/proxies/tor/etc to see if the ssh fingerprint match. Even with an ssl web page, you would have the same problem, unless you verify which CA issued the key and that you absolutely trust that they wouldn't issue a bogus certificate. btw: an easy way to check the key against an anoncvs server - $ cvs -d $CVSROOT -p src/etc/signify/openbsd-56-base.pub untrusted comment: openbsd 5.6 base public key RWR0EANmo9nqhpPbPUZDIBcRtrVcRwQxZ8UKGWY8Ui4RHi229KFL84wV
Re: provide public gpg key(s) by the install-isos
On 08-09-2014 19:14, Nicolai wrote: Lots of people use CVS over SSH to update their systems, and thus already have fingerprints saved in their known_hosts file. But how do you trust the initial fingerprint exchange? That's my point. In addition to checking multiple TLS-protected sites, which I previously mentioned, this is about as good as it gets. One can't ask for more. Where are these tls enable sites for getting the fingerprints? As far as I know, the only page (official) where you can get the ssh fingerprints of all the anoncvs servers is: http://www.openbsd.org/anoncvs.html This thread is about verifying signify pubkeys, not DNSSEC. DNSSEC is an unencrypted protocol that relies on RSA-1024 and governments. It's horribly complex, and I can't tell if it's a make-work program (incompetent) or Project Bullrun (malicious). Maybe both, which is why the US govt likes it so much. I mentioned DNSSEC because SSHFP records with it do seem better for getting the fingerprints than an unencrypted web page. But it won't happen, at least on any foreseeable future. Perhaps, if OpenBSD implement a DNSCURVE enable dns server with the ssh fingerprints, it would be better. But the problem is money and man power to implement it and keep it running. Anyway, in my previous post I shared several good methods for verifying the 5.5 base key, as well as the key itself, and any one of the thousands of people on this mailing list can pipe up to say, That's not the key I have! That could be a hugely compelling and important moment -- and if it happens then perhaps there's more to say on the issue. If you are being directed targeted, forget it. I'm not saying that you should just give up. I'm just saying that your attackers have much, much more resources than you'd possibly have. You might avoid getting compromised for some time, but eventually you'll be. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
Re: provide public gpg key(s) by the install-isos
On 08-09-2014 20:09, Stuart Henderson wrote: Even with an ssl web page, you would have the same problem, unless you verify which CA issued the key and that you absolutely trust that they wouldn't issue a bogus certificate. Yes, the current TLS system with it's fucked up certificates authorities, are a problem. But it's better have than not to. btw: an easy way to check the key against an anoncvs server - $ cvs -d $CVSROOT -p src/etc/signify/openbsd-56-base.pub untrusted comment: openbsd 5.6 base public key RWR0EANmo9nqhpPbPUZDIBcRtrVcRwQxZ8UKGWY8Ui4RHi229KFL84wV Nice tip. Perhaps I'll implement a script to check it against all anoncvs servers to see if any of them disagree with mine. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
emul.linux on amd64
I know that at least in 2004 it was considered to be unreasonable to try to get i386 linux applications working on amd64 openbsd through emul.linux, but how much work would be involved to get amd64 linux apps working? Presumably it wouldn't quite be as easy as just using 64 bit packages instead of 32 bit, but are there too many abi differences?
Re: emul.linux on amd64
On Mon, Sep 8, 2014 at 8:49 PM, tekk t...@parlementum.net wrote: I know that at least in 2004 it was considered to be unreasonable to try to get i386 linux applications working on amd64 openbsd through emul.linux, but how much work would be involved to get amd64 linux apps working? Presumably it wouldn't quite be as easy as just using 64 bit packages instead of 32 bit, but are there too many abi differences? I don't know of anyone who has tried or done the work to compare the ABI details. Philip Guenther
