Re: diff to bsearch the autoconf vendor/product match tables
Date: Thu, 16 Dec 2010 02:39:47 +0200
From: Vladimir Kirillov pro...@uaoug.org.ua
Hello, t...@!
The pci/usb (and others) known_{products,vendors} generated from
{pci,usb}devs are really big and scanning them is not so efficient.
I took the reyk@'s bsearch() implementation found in ieee80211 code
and moved it to libkern.
To sort tables I've rewritten the devlist2h from awk to perl, since
it can sort :). Imho, this implementation is a bit cleaner and
does not have that big license header.
Since usb/pci is only supported so far, I hope if you like it I can
continue replacing the rest of autoconf matching goo to bsearch
What do you think?
My initial reaction is that you're trying to optimize something that
isn't worth optimizing.
Re: Allegations regarding OpenBSD IPSEC
On Wed, Dec 15, 2010 at 07:04:27PM +, Kevin Chadwick wrote: Jason L. Wright ja...@thought.net wrote: I cannot fathom his motivation for writing such falsehood The real work on OCF did not begin in earnest until February 2000. I can't see how this gives you credibility but maybe the people who worked with you at the time can understand how your evidence supports what you say. While the whole thing is most likely FUD, Perry did say Jason Wright and several other developers were responsible for those backdoors, and you would be well advised to review any and all code commits by Wright as well as the other developers he worked with originating from NETSEC. so it's not like Jason is the only one. Joachim
Re: slower logins
On Wed, Dec 15, 2010 at 09:42:52PM -0700, Bob Beck wrote: I don't mind [increasing the number of Blowfish rounds] if the eventual goal is to think about diddling with it per arch.. I certainly do NOT want a 2^11 blowfish password when logging into my sparc Why not? An attacker can, after all, brute-force your password on a machine of his choice. Silently decreasing the number of rounds on older architectures surprises the user in a way that can lead to password compromise (My password was brute-forced because I used it on a sparc?! I would have been fine on amd64? Huh? What happened to 'secure by default'?!) One *could* consider using a memory- instead of CPU-bound function to calculate the password hash. Since, historically, memory access times have increased less than effective CPU speeds, this may give decent security without penalizing old machines quite as much. Colin Percival (FreeBSD security officer) has proposed scrypt (security/scrypt; BSD license), which is supposed to be both memory- and CPU-bound. Perhaps you could do some test runs on your sparc to see if the above theory actually holds up? (Leaving open the question of whether OpenBSD should switch - bcrypt *is* more battle-tested.) FWIW, I've used 2^10 rounds for years and never had any problems. Then again, I've only used machines made in the last 10 years... Joachim
set loginterface [if|ifgroup|none|all]
Hi,
I took a leap of faith and discovered some options not mentioned
in pf.conf(5). What do you think of this patch?
Index: share/man/man5/pf.conf.5
===
RCS file: /cvs/src/share/man/man5/pf.conf.5,v
retrieving revision 1.476
diff -u -r1.476 pf.conf.5
--- share/man/man5/pf.conf.519 May 2010 13:51:37 - 1.476
+++ share/man/man5/pf.conf.516 Dec 2010 09:49:23 -
@@ -1057,15 +1057,15 @@
.Pp
.Dl # pfctl -s info
.Pp
-In this example
+You can set on which interfaces
.Xr pf 4
-collects statistics on the interface named dc0:
+collects statistics with:
.Pp
-.Dl set loginterface dc0
+.Dl set loginterface [if|ifgroup|none|all]
.Pp
-One can disable the loginterface using:
+For example, you can enable logging both bge0 and bge1 with:
.Pp
-.Dl set loginterface none
+.Dl set loginterface bge
.It Ar set optimization
Optimize state timeouts for one of the following network environments:
.Pp
@@ -2608,7 +2608,7 @@
[ optimization [ default | normal | high-latency |
satellite | aggressive | conservative ] ]
[ limit ( limit-item | { limit-list } ) ] |
- [ loginterface ( interface-name | none ) ] |
+ [ loginterface ( interface-name | interface-group | none
| all ) ] |
[ block-policy ( drop | return ) ] |
[ state-policy ( if-bound | floating ) ]
[ state-defaults state-opts ]
# Han
Re: set loginterface [if|ifgroup|none|all]
if memory serves set logingterface for anything but a single
interface doesn't lead to the intended results, so this is on purpose.
unless you fix the code so that pfctl -si shows the sum for all
interfaces in the given group, there is no point at all.
* Han Boetes h...@mijncomputer.nl [2010-12-16 12:16]:
Hi,
I took a leap of faith and discovered some options not mentioned
in pf.conf(5). What do you think of this patch?
Index: share/man/man5/pf.conf.5
===
RCS file: /cvs/src/share/man/man5/pf.conf.5,v
retrieving revision 1.476
diff -u -r1.476 pf.conf.5
--- share/man/man5/pf.conf.5 19 May 2010 13:51:37 - 1.476
+++ share/man/man5/pf.conf.5 16 Dec 2010 09:49:23 -
@@ -1057,15 +1057,15 @@
.Pp
.Dl # pfctl -s info
.Pp
-In this example
+You can set on which interfaces
.Xr pf 4
-collects statistics on the interface named dc0:
+collects statistics with:
.Pp
-.Dl set loginterface dc0
+.Dl set loginterface [if|ifgroup|none|all]
.Pp
-One can disable the loginterface using:
+For example, you can enable logging both bge0 and bge1 with:
.Pp
-.Dl set loginterface none
+.Dl set loginterface bge
.It Ar set optimization
Optimize state timeouts for one of the following network environments:
.Pp
@@ -2608,7 +2608,7 @@
[ optimization [ default | normal | high-latency |
satellite | aggressive | conservative ] ]
[ limit ( limit-item | { limit-list } ) ] |
- [ loginterface ( interface-name | none ) ] |
+ [ loginterface ( interface-name | interface-group |
none | all ) ] |
[ block-policy ( drop | return ) ] |
[ state-policy ( if-bound | floating ) ]
[ state-defaults state-opts ]
# Han
--
Henning Brauer, h...@bsws.de, henn...@openbsd.org
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting
Re: slower logins
On Thu, Dec 16, 2010 at 4:35 AM, Joachim Schipper joac...@joachimschipper.nl wrote: On Wed, Dec 15, 2010 at 09:42:52PM -0700, Bob Beck wrote: I don't mind [increasing the number of Blowfish rounds] if the eventual goal is to think about diddling with it per arch.. I certainly do NOT want a 2^11 blowfish password when logging into my sparc Why not? An attacker can, after all, brute-force your password on a machine of his choice. Silently decreasing the number of rounds on older architectures surprises the user in a way that can lead to password compromise (My password was brute-forced because I used it on a sparc?! I would have been fine on amd64? Huh? What happened to 'secure by default'?!) At some point, you won't be able to compute the hash before the login timeout of 5 minutes expires. Hopefully, the people using old machines are using them for fun, not in a setting where master.passwd is likely to be stolen. That's really what it's about. Is your machine likely to have the passwd file stolen and are the accounts and passwords in that file worth cracking?
Re: slower logins
On 16 December 2010 05:38, Mike Belopuhov m...@crypt.org.ru wrote: I was about to do the same and do some measurements to back my words up, but got distracted. I'm strongly in a favor of increasing number of rounds at least to 2^8. Solar Designer uses this number of rounds in Openwall for quite some time now. I don't have a problem with doing this for modern arch's doing it at the expense of the old stuff is silly. and the old stuff is important. it finds bugs that keep you all secure.
Re: slower logins
On Thu, Dec 16, 2010 at 08:14:06AM -0700, Bob Beck wrote: Why not? An attacker can, after all, brute-force your password on a machine of his choice. Silently decreasing the number of rounds on older architectures surprises the user in a way that can lead to password compromise (My password was brute-forced because I used it on a sparc?! I would have been fine on amd64? Huh? What happened to 'secure by default'?!) .. and I only use new machines... And that is exactly my point. By your logic let's switch you to a 2^25 round blowfish on you dumbass. you'd be incredibly secure. Show me colin percivals' peer reviewed paper about this new scheme, and where it has been compared to bcrypt. then go read neil's paper on the subject please. My message was too emotional, and for that I apologize. Sorry. I share your concern for the newness of scrypt, and in fact I edited out a sentence to that effect. With respect to the paper: are you talking about A Future-Adaptable Password Scheme by Niels Provos and David Mazihres? If not, my Google-fu failed me and I would, honestly, appreciate a pointer to said paper. Joachim
uticom firmware
This diff makes the uticom(4) driver work on my machine with an Abbott USB
converter, which is used to connect to the Abbott Freestyle series glucose
meter.
This makes the firmware loading work again.
Index: usbdevs
===
RCS file: /home/cvsync/src/sys/dev/usb/usbdevs,v
retrieving revision 1.531
diff -u -r1.531 usbdevs
--- usbdevs 15 Dec 2010 16:49:03 - 1.531
+++ usbdevs 16 Dec 2010 21:38:55 -
@@ -548,6 +548,7 @@
vendor ZTE 0x19d2 ZTE Inc.
vendor QUANTA 0x1a32 Quanta
vendor TERMINUS0x1a40 Terminus Technology
+vendor ABBOTT 0x1a61 Abbott Labs
vendor BAYER 0x1a79 Bayer Health Care
vendor WCH20x1a86 QinHeng Electronics
vendor MATRIXORB 0x1b3d Matrix Orbital
@@ -635,6 +636,9 @@
product 3COMUSR USR56K 0x3021 U.S.Robotics 56000
product HUAWEI3COM WUB320G 0x0009 Aolynk WUB320g
+
+/* Abbott products */
+product ABBOTT STEREO_PLUG 0x3410 Stereo Plug Cable
/* AboCom products */
product ABOCOM XX1 0x110c XX1
Index: usbdevs.h
===
RCS file: /home/cvsync/src/sys/dev/usb/usbdevs.h,v
retrieving revision 1.541
diff -u -r1.541 usbdevs.h
--- usbdevs.h 15 Dec 2010 16:51:39 - 1.541
+++ usbdevs.h 16 Dec 2010 21:38:55 -
@@ -1,4 +1,4 @@
-/* $OpenBSD: usbdevs.h,v 1.541 2010/12/15 16:51:39 damien Exp $*/
+/* $OpenBSD$ */
/*
* THIS FILE IS AUTOMATICALLY GENERATED. DO NOT EDIT.
@@ -555,6 +555,7 @@
#defineUSB_VENDOR_ZTE 0x19d2 /* ZTE Inc. */
#defineUSB_VENDOR_QUANTA 0x1a32 /* Quanta */
#defineUSB_VENDOR_TERMINUS 0x1a40 /* Terminus Technology
*/
+#defineUSB_VENDOR_ABBOTT 0x1a61 /* Abbott Labs */
#defineUSB_VENDOR_BAYER0x1a79 /* Bayer Health Care */
#defineUSB_VENDOR_WCH2 0x1a86 /* QinHeng Electronics */
#defineUSB_VENDOR_MATRIXORB0x1b3d /* Matrix Orbital */
@@ -642,6 +643,9 @@
#defineUSB_PRODUCT_3COMUSR_USR56K 0x3021 /* U.S.Robotics
56000 */
#defineUSB_PRODUCT_HUAWEI3COM_WUB320G 0x0009 /* Aolynk
WUB320g */
+
+/* Abbott products */
+#defineUSB_PRODUCT_ABBOTT_STEREO_PLUG 0x3410 /* Stereo Plug
Cable */
/* AboCom products */
#defineUSB_PRODUCT_ABOCOM_XX1 0x110c /* XX1 */
Index: usbdevs_data.h
===
RCS file: /home/cvsync/src/sys/dev/usb/usbdevs_data.h,v
retrieving revision 1.535
diff -u -r1.535 usbdevs_data.h
--- usbdevs_data.h 15 Dec 2010 16:51:39 - 1.535
+++ usbdevs_data.h 16 Dec 2010 21:38:55 -
@@ -1,4 +1,4 @@
-/* $OpenBSD: usbdevs_data.h,v 1.535 2010/12/15 16:51:39 damien Exp $
*/
+/* $OpenBSD$ */
/*
* THIS FILE IS AUTOMATICALLY GENERATED. DO NOT EDIT.
@@ -118,6 +118,10 @@
Aolynk WUB320g,
},
{
+ USB_VENDOR_ABBOTT, USB_PRODUCT_ABBOTT_STEREO_PLUG,
+ Stereo Plug Cable,
+ },
+ {
USB_VENDOR_ABOCOM, USB_PRODUCT_ABOCOM_XX1,
XX1,
},
@@ -11716,6 +11720,10 @@
{
USB_VENDOR_TERMINUS,
Terminus Technology,
+ },
+ {
+ USB_VENDOR_ABBOTT,
+ Abbott Labs,
},
{
USB_VENDOR_BAYER,
Index: uticom.c
===
RCS file: /home/cvsync/src/sys/dev/usb/uticom.c,v
retrieving revision 1.10
diff -u -r1.10 uticom.c
--- uticom.c15 Dec 2010 16:22:16 - 1.10
+++ uticom.c16 Dec 2010 21:38:55 -
@@ -119,7 +119,7 @@
};
struct uticom_softc {
- struct devicesc_dev;/* base device */
+ struct devicesc_dev;/* base device */
usbd_device_handle sc_udev; /* device */
usbd_interface_handlesc_iface; /* interface */
@@ -158,6 +158,8 @@
static int uticom_open(void *, int);
static void uticom_close(void *, int);
+void uticom_attach_hook(void *arg);
+
static int uticom_download_fw(struct uticom_softc *sc, int pipeno,
usbd_device_handle dev);
@@ -191,7 +193,8 @@
static const struct usb_devno uticom_devs[] = {
{ USB_VENDOR_TI, USB_PRODUCT_TI_TUSB3410 },
- { USB_VENDOR_STARTECH, USB_PRODUCT_STARTECH_ICUSB232X }
+ { USB_VENDOR_STARTECH, USB_PRODUCT_STARTECH_ICUSB232X },
+ { USB_VENDOR_ABBOTT, USB_PRODUCT_ABBOTT_STEREO_PLUG }
};
int
@@ -209,26 +212,37 @@
void
uticom_attach(struct device *parent, struct device *self, void *aux)
{
- struct uticom_softc *sc = (struct uticom_softc *)self;
- struct usb_attach_arg *uaa = aux;
- usbd_device_handle dev = uaa-device;
- usb_config_descriptor_t *cdesc;
-
Re: Allegations regarding OpenBSD IPSEC
I'm not going to comment on the mail itself, but I've seen a lot of incredibly dubious articles on the net over the last few days. - use your brains, people. Just because a guy does say so doesn't mean there's a backdoor. Ever heard about FUD ? - of course OpenBSD is going to check. Geeez!! what do you think ? - why would OpenBSD be in trouble ? where do you think *all the other IPsec implementations* come from ? (hint: 10 years ago, what was the USofA view on cryptography exports ? where is OpenBSD based. Second hint: Canada != UsOfA). - why would the FBI only target OpenBSD ? if there's a backhole in OpenBSD, which hosts some of the most paranoid Opensource developers alive, what do you think is the likelyhood similar backholes exist in, say, Windows, or MacOs, or Linux (check where their darn IPsec code comes from, damn it!) I know that a lot of the guys reading tech@ are intelligent enough to *know* all the rather obvious things I'm stating here, but it's looking like a lot of stupid, stupid web sites are using this as their *only* source of information, and do not engage their brain): if you read french, go check http://www.macgeneration.com/news/voir/180982/un-systeme-espion-du-fbi-dans-openbsd and be amazed at how clueless those writers are. Just on the off chance that those idiots will read this, and realize how stupid their generalizations are. Theo was careful enough to state facts, and I'm a huge fan of what he's done (he's decided to go fully open with this, which was a tough decision). I don't see why this would impact OpenBSD negatively without affecting any other OS... especially until we actually get proof...
Re: Allegations regarding OpenBSD IPSEC
I about talked myself out of believing that this happened after explaining this to a cow-orker today. They were quite surprised i'd buy into something this speculative and far fetched at all. After listening to him generalize it back to me it seems even sillier. Brandon On Dec 16, 2010 6:34 PM, Marc Espie es...@nerim.net wrote: I'm not going to comment on the mail itself, but I've seen a lot of incredibly dubious articles on the net over the last few days. - use your brains, people. Just because a guy does say so doesn't mean there's a backdoor. Ever heard about FUD ? - of course OpenBSD is going to check. Geeez!! what do you think ? - why would OpenBSD be in trouble ? where do you think *all the other IPsec implementations* come from ? (hint: 10 years ago, what was the USofA view on cryptography exports ? where is OpenBSD based. Second hint: Canada != UsOfA). - why would the FBI only target OpenBSD ? if there's a backhole in OpenBSD, which hosts some of the most paranoid Opensource developers alive, what do you think is the likelyhood similar backholes exist in, say, Windows, or MacOs, or Linux (check where their darn IPsec code comes from, damn it!) I know that a lot of the guys reading tech@ are intelligent enough to *know* all the rather obvious things I'm stating here, but it's looking like a lot of stupid, stupid web sites are using this as their *only* source of information, and do not engage their brain): if you read french, go check http://www.macgeneration.com/news/voir/180982/un-systeme-espion-du-fbi-dans-openbsd and be amazed at how clueless those writers are. Just on the off chance that those idiots will read this, and realize how stupid their generalizations are. Theo was careful enough to state facts, and I'm a huge fan of what he's done (he's decided to go fully open with this, which was a tough decision). I don't see why this would impact OpenBSD negatively without affecting any other OS... especially until we actually get proof...
Re: Allegations regarding OpenBSD IPSEC
On Fri, 17 Dec 2010 00:30:27 +0100, Marc Espie wrote: if you read french, go check http://www.macgeneration.com/news/voir/180982/un-systeme-espion-du-fbi-dans-openbsd and be amazed at how clueless those writers are. Gee, even the google page translation makes it clearer than my rusty frangais (` mon icole secondaire de trop nombreuses annies il ya). Thanks for the laughs, Marc. *** NOTE *** Please DO NOT CC me. I am subscribed to the list. Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou. Rod/ --- This life is not the real thing. It is not even in Beta. If it was, then OpenBSD would already have a man page for it.
Re: Allegations regarding OpenBSD IPSEC
On Thu, Dec 16, 2010 at 4:47 AM, Joachim Schipper joac...@joachimschipper.nl wrote: On Wed, Dec 15, 2010 at 07:04:27PM +, Kevin Chadwick wrote: Jason L. Wright ja...@thought.net wrote: I cannot fathom his motivation for writing such falsehood The real work on OCF did not begin in earnest until February 2000. I can't see how this gives you credibility but maybe the people who worked with you at the time can understand how your evidence supports what you say. While the whole thing is most likely FUD, Perry did say Jason Wright and several other developers were responsible for those backdoors, and you would be well advised to review any and all code commits by Wright as well as the other developers he worked with originating from NETSEC. so it's not like Jason is the only one. Joachim OpenBSD is a great product, but y'all are too easily trolled. His NDA with the FBI *expired* so he 1) discloses information that's privileged at the very least and a political stick of dynamite at worst, 2) discloses it in a private forum to an individual known for his transparency and total lack of tact, 3) doesn't bother contacting anyone in the press about it, 4) claims to know various other pundits are on the FBI payroll, and 5) claims that the FBI deliberately compromised an open source project in order to spy on its parent organization and other government agencies. Here's a tip: when a government organization works with private contractors to help them spy on other government organizations, those NDAs don't fucking expire. Jesus.
Re: Allegations regarding OpenBSD IPSEC
On Friday, 17 December 2010, (private) HKS hks.priv...@gmail.com wrote: On Thu, Dec 16, 2010 at 4:47 AM, Joachim Schipper joac...@joachimschipper.nl wrote: On Wed, Dec 15, 2010 at 07:04:27PM +, Kevin Chadwick wrote: Jason L. Wright ja...@thought.net wrote: I cannot fathom his motivation for writing such falsehood The real work on OCF did not begin in earnest until February 2000. I can't see how this gives you credibility but maybe the people who worked with you at the time can understand how your evidence supports what you say. While the whole thing is most likely FUD, Perry did say Jason Wright and several other developers were responsible for those backdoors, and you would be well advised to review any and all code commits by Wright as well as the other developers he worked with originating from NETSEC. so it's not like Jason is the only one. Joachim OpenBSD is a great product, but y'all are too easily trolled. His NDA with the FBI *expired* so he 1) discloses information that's privileged at the very least and a political stick of dynamite at worst, 2) discloses it in a private forum to an individual known for his transparency and total lack of tact, 3) doesn't bother contacting anyone in the press about it, 4) claims to know various other pundits are on the FBI payroll, and 5) claims that the FBI deliberately compromised an open source project in order to spy on its parent organization and other government agencies. Here's a tip: when a government organization works with private contractors to help them spy on other government organizations, those NDAs don't fucking expire. Jesus. That is what I would expect. From memory, in my part of the World if you did this sort of work for an intelligence agency, your role and work is kept secret until 40 years *after* your death.
Re: Allegations regarding OpenBSD IPSEC
I about talked myself out of believing that this happened after explaining this to a cow-orker today. They were quite surprised i'd buy into something this speculative and far fetched at all. After listening to him generalize it back to me it seems even sillier. I think you are totally misreading espie. It is an allegation in a world where we audit whether there is an allegation or not. If I read you right, what you are saying can be simplified to this: Because this is an allegation, we need not audit. Hey, let's post instead! I am sorry, but even if you don't mean it exactly like that, what you said will be interpreted by many people to mean that. What I see you say above ridiculous. You can say keep interpreting things so simplistically, but some of us are not saying much because we are studying and re-learning the workings of the ipsec and crypto layers works because that is what we do.
