Re: osfp pfctl and states

2013-09-12 Thread Henning Brauer
* sven falempin sven.falem...@gmail.com [2013-09-11 22:30]: At his point struct pf_state **sm is available. Lets assume pf_state got a struct pf_osfp_enlist l_osfp To get back the info from userland, doing Would a diff like this hurts ?? everything that grows the state hurts (last not

Re: Iso image integrity verification

2013-09-12 Thread InterNetX - Robert Garrett
The real problem here is that in order to be added to certain lists of trusted PKI providers, you must be audited by security Assessors one of the things they look for is proof that the software your using isnt tampered with. It appears the OP is trying to solve that issue. EVEN using the CD

Re: osfp pfctl and states

2013-09-12 Thread sven falempin
On Thu, Sep 12, 2013 at 2:50 AM, Henning Brauer lists-openbsdt...@bsws.dewrote: * sven falempin sven.falem...@gmail.com [2013-09-11 22:30]: At his point struct pf_state **sm is available. Lets assume pf_state got a struct pf_osfp_enlist l_osfp To get back the info from userland, doing

Re: Iso image integrity verification

2013-09-12 Thread Kenneth R Westerback
On Thu, Sep 12, 2013 at 10:49:30AM +0200, InterNetX - Robert Garrett wrote: The real problem here is that in order to be added to certain lists of trusted PKI providers, you must be audited by security Assessors one of the things they look for is proof that the software your using isnt

Re: defer routing table updates on link state changes

2013-09-12 Thread Reyk Floeter
On Thu, Sep 12, 2013 at 06:51:46AM +0200, Claudio Jeker wrote: On Tue, Aug 27, 2013 at 01:39:14PM +0200, Martin Pieuchot wrote: I think that's the right approach but the current code generating interfaces indexes is too clever from my point of view, it tries to reuse the last index if

Re: defer routing table updates on link state changes

2013-09-12 Thread Mike Belopuhov
On 12 September 2013 17:18, Martin Pieuchot mpieuc...@nolizard.org wrote: FWIW it would be interesting to modify tun(4) so that it doesn't need to detach/reattach itself when switching between mode, this would allow us to stop reusing the last index. this definitely makes a lot of sense.

Re: defer routing table updates on link state changes

2013-09-12 Thread Reyk Floeter
On Thu, Sep 12, 2013 at 05:18:39PM +0200, Martin Pieuchot wrote: For example, you have to query the IfIndex via SNMP to get further information, like the ifName or statistics, and most monitoring systems would save interface information based on the index - they would not recognize that

Re: defer routing table updates on link state changes

2013-09-12 Thread Martin Pieuchot
On 12/09/13(Thu) 16:40, Reyk Floeter wrote: On Thu, Sep 12, 2013 at 06:51:46AM +0200, Claudio Jeker wrote: On Tue, Aug 27, 2013 at 01:39:14PM +0200, Martin Pieuchot wrote: I think that's the right approach but the current code generating interfaces indexes is too clever from my point of

Re: defer routing table updates on link state changes

2013-09-12 Thread Mike Belopuhov
On 12 September 2013 17:31, Reyk Floeter r...@openbsd.org wrote: On Thu, Sep 12, 2013 at 05:18:39PM +0200, Martin Pieuchot wrote: For example, you have to query the IfIndex via SNMP to get further information, like the ifName or statistics, and most monitoring systems would save interface

Re: defer routing table updates on link state changes

2013-09-12 Thread Reyk Floeter
On Thu, Sep 12, 2013 at 07:19:34PM +0200, Mike Belopuhov wrote: either way, we need to move forward on this. we want to use if_index for the purpose of looking up the interface w/o a pointer to the ifnet. should we implement additional indices for that or snmp problem will be dealt with?

Re: defer routing table updates on link state changes

2013-09-12 Thread Mike Belopuhov
On 12 September 2013 18:28, Mike Belopuhov m...@belopuhov.com wrote: On 12 September 2013 18:14, Reyk Floeter r...@openbsd.org wrote: On Thu, Sep 12, 2013 at 05:53:42PM +0200, Mike Belopuhov wrote: looks like you misunderstand the problem we're dealing with here. Sure, I do. You're trying

Re: defer routing table updates on link state changes

2013-09-12 Thread Reyk Floeter
On Thu, Sep 12, 2013 at 06:28:15PM +0200, Mike Belopuhov wrote: Sure, I do. You're trying to push one thing and you don't want to hear the concerns about a specific detail of it. with all respect, i think you don't. otherwise you wouldn't be asking the questions you're asking. we do

Re: defer routing table updates on link state changes

2013-09-12 Thread Mike Belopuhov
On 12 September 2013 18:14, Reyk Floeter r...@openbsd.org wrote: On Thu, Sep 12, 2013 at 05:53:42PM +0200, Mike Belopuhov wrote: looks like you misunderstand the problem we're dealing with here. Sure, I do. You're trying to push one thing and you don't want to hear the concerns about a

Re: defer routing table updates on link state changes

2013-09-12 Thread Henning Brauer
* Mike Belopuhov m...@belopuhov.com [2013-09-12 17:54]: it makes no sense whatsoever, reyk. those indices can be easily stolen and nobody guarantees that if you create vlan10, vlan11, then destroy vlan10, create vlan12 and vlan10 that vlan10 will have the same index as before. in fact it

Re: defer routing table updates on link state changes

2013-09-12 Thread Mike Belopuhov
On 12 September 2013 19:07, Reyk Floeter r...@openbsd.org wrote: On Thu, Sep 12, 2013 at 06:59:13PM +0200, Mike Belopuhov wrote: Ok, let's stop this. I don't think you read what I replied before. I didn't say that we're static with if_indexes, just that we shouldn't make it worse. or

Re: defer routing table updates on link state changes

2013-09-12 Thread Mike Belopuhov
On 12 September 2013 18:48, Reyk Floeter r...@openbsd.org wrote: On Thu, Sep 12, 2013 at 06:28:15PM +0200, Mike Belopuhov wrote: Sure, I do. You're trying to push one thing and you don't want to hear the concerns about a specific detail of it. with all respect, i think you don't.

Re: defer routing table updates on link state changes

2013-09-12 Thread Reyk Floeter
On Thu, Sep 12, 2013 at 05:53:42PM +0200, Mike Belopuhov wrote: looks like you misunderstand the problem we're dealing with here. Sure, I do. You're trying to push one thing and you don't want to hear the concerns about a specific detail of it. FWIW it would be interesting to modify tun(4)

Re: Iso image integrity verification

2013-09-12 Thread Otto Moerbeek
On Thu, Sep 12, 2013 at 09:22:51AM -0400, Kenneth R Westerback wrote: On Thu, Sep 12, 2013 at 10:49:30AM +0200, InterNetX - Robert Garrett wrote: The real problem here is that in order to be added to certain lists of trusted PKI providers, you must be audited by security Assessors one of

Re: defer routing table updates on link state changes

2013-09-12 Thread Philip Guenther
On Thu, Sep 12, 2013 at 10:19 AM, Mike Belopuhov m...@belopuhov.com wrote: ... either way, we need to move forward on this. we want to use if_index for the purpose of looking up the interface w/o a pointer to the ifnet. This sounds like just using a pid to identify processes and hoping they

Re: defer routing table updates on link state changes

2013-09-12 Thread Reyk Floeter
On Thu, Sep 12, 2013 at 06:59:13PM +0200, Mike Belopuhov wrote: Ok, let's stop this. I don't think you read what I replied before. I didn't say that we're static with if_indexes, just that we shouldn't make it worse. or implement persistent indices in the snmpd itself maybe? Maybe.

Re: Iso image integrity verification

2013-09-12 Thread Kenneth R Westerback
On Thu, Sep 12, 2013 at 07:52:22PM +0300, Valentin Zagura wrote: There is no entity that owns or can be held responsible for the code, or is capable of providing a solid evidentuary path from commit to your hands. I thought if we buy the CDs we WILL get a solid evidentuary path from

Re: Iso image integrity verification

2013-09-12 Thread Daniel Bolgheroni
On Thu, Sep 12, 2013 at 07:52:22PM +0300, Valentin Zagura wrote: I thought if we buy the CDs we WILL get a solid evidentuary path from commit to our hands. So this isn't the case? You'll be safe enough.

Re: Iso image integrity verification

2013-09-12 Thread sven falempin
Can the project wire an explosive booby trap inside the CD box to ensure that any sneaky postman is blown away by the awesomeness of openBSD ? (for a decent supplementary fee of course) On Thu, Sep 12, 2013 at 6:56 PM, Kenneth R Westerback kwesterb...@rogers.com wrote: On Thu, Sep 12, 2013