ld.so fix for empty LD_PRELOAD
$ export LD_PRELOAD='' $ sed sed: can't load library '' $ env env: can't load library '' $ vim /usr/local/bin/vim: can't load library '' $ Is this the right way to fix it? Index: loader.c === RCS file: /cvs/src/libexec/ld.so/loader.c,v retrieving revision 1.120 diff -u -p -r1.120 loader.c --- loader.c25 Oct 2010 20:34:44 - 1.120 +++ loader.c16 Dec 2010 21:40:07 - @@ -493,7 +493,7 @@ _dl_boot(const char **argv, char **envp, TAILQ_INSERT_TAIL(&_dlopened_child_list, n, next_sib); exe_obj->opencount++; - if (_dl_preload != NULL) + if (_dl_preload != NULL && _dl_preload[0] != '\0') _dl_dopreload(_dl_preload); _dl_load_dep_libs(exe_obj, exe_obj->obj_flags, 1);
Vacante si proprietati
Daca aveti probleme cu vizionarea acestui email dati [click aici] pentru a vizualiza varianta online! [IMAGE] [IMAGE] Newsletter 14.12.2010 [IMAGE] CaseFaraIntermediari.roUrmariti-ne pe Facebook!Urmariti-ne pe Twitter!Urmariti-ne pe Blogger! Ultimele anunturi adaugate Vezi toate anunturile [IMAGE] [IMAGE] Vila 4 camere - Bucurestii Noi Vila 4 camere - Bucurestii Noi 2.800 EUR/luna INCHIRIERE DETALII ; [IMAGE] [IMAGE] [IMAGE] [IMAGE] Vila 4 camere - Bucurestii Noi Vila 4 camere - Bucurestii Noi 700.000 EUR VANZARE DETALII ; [IMAGE] [IMAGE] [IMAGE] [IMAGE] Apartament 2 camere - Viilor, Bucuresti Apartament 2 camere - Viilor, Bucuresti 42.000 EUR VANZARE DETALII ; [IMAGE] [IMAGE] [IMAGE] [IMAGE] Pensiunea Casa Armenia - Predeal Pensiunea Casa Armenia - Predeal 750.000 EUR VANZARE DETALII ; [IMAGE] [IMAGE] [IMAGE] [IMAGE] Garsoniera - Soseaua Andronache, Bucuresti Garsoniera - Soseaua Andronache, Bucuresti 40.000 EUR VANZARE DETALII ; [IMAGE] [IMAGE] Publica si tu un anunt! [IMAGE] Stiri Imobiliare Vezi toate stirile [IMAGE] [IMAGE] Soc pe piata asigurarilor: Basescu promulga legea care spune ca o locuinta asigurata facultativ nu mai intra in schema obligatorie Soc pe piata asigurarilor: Basescu promulga legea care spune ca o locuinta asigurata facultativ nu mai intra in schema obligatorie Presedintele Traian Basescu a promulgat ieri legea care elimina necesitatea incheierii unei pol! ite obligatorii de asigurare a locuintei pentru proprietarii care au cumparat deja o asigurare facultativa care acopera daunele produse de inundatii, cutremure E i alunecari de teren. Companiile de ...[CITESTE TOT] [IMAGE] [IMAGE] [IMAGE] [IMAGE] Imobiliarii spun B+hopB;, chiar daca n-a trecut criza Imobiliarii spun B+hopB;, chiar daca n-a trecut criza Tranzactiile importante incheiate in ultima perioada au descretit fruntile investitorilor din piata imobiliara. Principalul energizant a fost, desigur, vbnzarea complexului de birouri Floreasca Business Park pentru 100 milioane de euro, singura de asemenea anvergurD de la nnceputul ...[CITESTE TOT] [IMAGE] [IMAGE] [IMAGE] [IMAGE] Banca Mondiala a platit 210 mil. $ pe o cladire de birouri din Washington Banca Mondiala a platit 210 mil. $ pe o cladire de birouri din Washington Brookfield Properties Corp vandut o cladire de birouri de opt etaje, din Washington, pentru 216 milioane dolari. Proprietatea a fost achizitionata de catre Banca Mondiala, scrie Bloomberg. Banca Mondiala ocupa inca din anul 2008 intreaga cladire, de 240.000 de metri patrati, conform sursei ...[CITESTE TOT] [IMAGE] [IMAGE] Oferte turistice Vezi toate ofertele [IMAGE] [IMAGE] Complexul Lacul Sarat - Ocna Sugatag, Maramures Complexul Lacul Sarat - Ocna Sugatag, Maramures negociabil INCHIRIERE DETALII ; [IMAGE] [IMAGE] [IMAGE] [IMAGE] Pensiunea Green Eden - Busteni Pensiunea Green Eden - Busteni negociabil INCHIRIERE DETALII ; [IMAGE] [IMAGE] [IMAGE] [IMAGE] Pensiunea Adina - Moieciu, Brasov Pensiunea Adina - Moieciu, Brasov negociabil INCHIRIERE DETALII ; [IMAGE] [IMAGE] [IMAGE] [IMAGE] Pensiunea Poiana Verde - Bran, Brasov Pensiunea Poiana Verde - Bran, Brasov 350 EUR/luna INCHIRIERE DETALII ; [IMAGE] [IMAGE] [IMAGE] [IMAGE] Pensiunea Casa Radacina - Moieciu, Brasov Pensiunea Casa Radacina - Moieciu, Brasov negociabil INCHIRIERE DETALII ; [IMAGE] [IMAGE] Publica si tu un anunt! Stiri economice Vezi toate stirile [IMAGE] [IMAGE] Adio reclame in centru! Adio reclame in centru! Interdictie. Afisele si panourile publicitare ar putea sa dispara din Centrul istoric si de pe marile bulevarde bucurestene daca proiectul va fi votat in sedinta de vineri a Consiliului General al Municipiului Bucuresti. Astfel, in Piata Universitatii, Piata Romana, pe bulevardele Balcescu, ...[CITESTE TOT] [IMAGE] [IMAGE] [IMAGE] [IMAGE] H&M recruteaza pana la sfarsitul anului! Vezi pe ce pozitii poti sa te angajezi! H&M recruteaza pana la sfarsitul anului! Vezi pe ce pozitii poti sa te angajezi! Dupa ce in ultimele doua luni retailerul suedez de imbracaminte H&M a facut recrutari pentru pozitiile de director de magazin, manager de departament sau pentru merchandiser (activitDE#i de promovare), compania, ca! re va intra pe piata din Romania in primavara anului 2011, cauta acum asistenti ...[CITESTE TOT] [IMAGE] [IMAGE] [IMAGE] [IMAGE] Inmatricularile de masini rulate aproape s-au dublat, pe fondul cresterii taxei auto din 2011 Inmatricularile de masini rulate aproape s-au dublat, pe fondul cresterii taxei auto din 2011 Inmatricularile de autoturisme second-hand au inregistrat in luna noiembrie cel mai ridicat nivel al acestui an, de 26.887 unitati, in crestere cu peste 80% faE#D de aceeasi luna a anului trecut, ca urmare a deciziei Ministerului Mediului de a majora taxa de poluare incepand cu 1 ianuarie 2011. ...[CITESTE TOT] [IMAGE] [IMAGE] Scoala romaneasca Vezi toate s
Re: Allegations regarding OpenBSD IPSEC
On Thu, Dec 16, 2010 at 3:30 PM, Marc Espie 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. B Ever heard about FUD ? > > - of course OpenBSD is going to check. Geeez!! what do you think ? I'm really sorry to pitch in here, but... The centerpiece of this thread, besides technical details of how/whether to prove/disprove the so-called accusations, seems to be an argument on whether Perry's purely FUD'ing, promoting his company/pages, creating the buzz, or whether his words should be taken for their face value. I have to say that Perry here is credited with one thing he actually did not do -- publish this to the world. There has been talk of alterior motives here, but for any of these motives, Perry had to know or pretty damn well guessed that the second thing Theo (hi, Theo) would do to his email was to publish it. Would you plan anything based on a predicted behavior of a person you haven't communicated with in 10 years? This is not to point finger at Theo for creating all this commotion, of course; this commotion can, however, be, an unintended accident, but the fact that it came from Theo gave it a lot of credibility. [skipped]
Re: ld.so fix for empty LD_PRELOAD
> Date: Thu, 16 Dec 2010 22:43:04 +0100 > From: Stefan Sperling > > $ export LD_PRELOAD='' > $ sed > sed: can't load library '' > $ env > env: can't load library '' > $ vim > /usr/local/bin/vim: can't load library '' > $ > > Is this the right way to fix it? I'd say it works just fine without your fix. If you really don't want to preload stuff, make sure LD_PRELOAD isn't set at all. > Index: loader.c > === > RCS file: /cvs/src/libexec/ld.so/loader.c,v > retrieving revision 1.120 > diff -u -p -r1.120 loader.c > --- loader.c 25 Oct 2010 20:34:44 - 1.120 > +++ loader.c 16 Dec 2010 21:40:07 - > @@ -493,7 +493,7 @@ _dl_boot(const char **argv, char **envp, > TAILQ_INSERT_TAIL(&_dlopened_child_list, n, next_sib); > exe_obj->opencount++; > > - if (_dl_preload != NULL) > + if (_dl_preload != NULL && _dl_preload[0] != '\0') > _dl_dopreload(_dl_preload); > > _dl_load_dep_libs(exe_obj, exe_obj->obj_flags, 1);
Re: Allegations regarding OpenBSD IPSEC
Does anyone know if there was an ultimate outcome to the investigation of side channels supposedly put into DSA by the NSA?
Re: dhclient-script and resolv.conf
2010/12/15, Claudio Jeker : > This made me go nuts for a long time. As soon as you have two interfaces > running dhclient those two will start fighting over /etc/resolv.conf > which is realy bad when short lease times are used and one interface is > not getting new leases. Agreed. > This diff extends the dhclient-script in such a way that dhclient will > only restore the "old" resolv.conf file if it actually is in charge of the > current file. With this the fighting does not stop but is less > noticable. Have you considered using something like openresolv in the base system? I'll be probably reworking my RDNSS implementation in rtsold and rtadvd because of the new RFC 6106, which is already in "standards track". Of course it adds another fighter over resolv.conf... -- Martin Pelikan
Garantovano najniže cene!
Top Shop -10% za Vas i Vaše prijatelje Ne propustite super prazniD nu kupovinu po GARANTOVANO najniE>im cenama! Kupite šta god poE>elite uz kupon sa 10% popusta koji vaE>i za 1 kupovinu do 31.1.2011. Kod Vašeg kupona za 10% popusta je: 84ZEACSKJT Kliknite ovde i iskoristite odmah svoj popust! -10% popusta za Vas Pošaljite i prijateljima kupon za popust klikom ovde>>> Najpopularniji prazniD ni proizvodi: Relax & Tone - masaE>er (PrazniD na cena 4.491 rsd, redovna cena 4.990 rsd) Cardio Twister - fitnes sprava (PrazniD na cena 14.391 rsd, redovna cena 15.990 rsd) Door Gym - fitnes rekvizit (PrazniD na cena 2.241 rsd, redovna cena 2.490 rsd) Paint Zoom - kompresor za kreD enje (PrazniD na cena 6.741 rsd, redovna cena 7.490 rsd) *kupon moE>ete koristiti samo za online kupovinu, *kupon popust od 10% ne vaE>i za prizvode koji su veD na sniE>enju , * kupon vaE>i do 31.1.2011 i moE>e se koristiti samo za jednu porudE>binu Ovu elektronsku poštu primate, ukoliko ste svojevoljno ostavili svoju e-mail adresu na nekom od sajtova Top Shop-a, uD estvovali u našoj poklon igri ili nagradnom kvizu ili se prijavili za e-D asopis Top Shop-a ili nekog od nasih brendova. Ponude date u ovom e-mailu vaE>e iskljuD ivo za porudE>bine upuDene putem Interneta ili broja telefona 021 489 26 60. Ukoliko ne E>elite više da primate naše elektronske poruke, za odjavljivanje sa naše e-mailing liste, kliknite ovde. Studio Moderna d.o.o., Bulevar vojvode Stepe 30, 21000 Novi Sad, Tel: 021 489 26 60, Fax: 021 489 29 08, E-mail: i...@news.top-shop.rs [IMAGE]If you would no longer like to receive our emails please unsubscribe by clicking here.
Re: dhclient-script and resolv.conf
On Wed, Dec 15, 2010 at 04:08:23PM +0100, Claudio Jeker wrote:
> This made me go nuts for a long time. As soon as you have two interfaces
> running dhclient those two will start fighting over /etc/resolv.conf
> which is realy bad when short lease times are used and one interface is
> not getting new leases.
>
> This diff extends the dhclient-script in such a way that dhclient will
> only restore the "old" resolv.conf file if it actually is in charge of the
> current file. With this the fighting does not stop but is less
> noticable.
> --
> :wq Claudio
>
>
> Index: dhclient-script
> ===
> RCS file: /cvs/src/sbin/dhclient/dhclient-script,v
> retrieving revision 1.17
> diff -u -p -r1.17 dhclient-script
> --- dhclient-script 2 Jun 2010 09:57:16 - 1.17
> +++ dhclient-script 4 Nov 2010 11:18:59 -
> @@ -111,21 +111,21 @@ add_new_resolv_conf() {
> # $new_domain_name are provided. As reported in PR#3135, some ISPs
> # provide only $new_domain_name_servers.
>
> - rm -f /etc/resolv.conf.std
> + rm -f /etc/resolv.conf.$interface.std
>
> if [ -n "$new_domain_name" ]; then
> - echo "search $new_domain_name" >>/etc/resolv.conf.std
> + echo "search $new_domain_name" >>/etc/resolv.conf.$interface.std
> fi
>
> if [ -n "$new_domain_name_servers" ]; then
> for nameserver in $new_domain_name_servers; do
> - echo "nameserver $nameserver" >>/etc/resolv.conf.std
> + echo "nameserver $nameserver"
> >>/etc/resolv.conf.$interface.std
> done
> fi
>
> - if [ -f /etc/resolv.conf.std ]; then
> + if [ -f /etc/resolv.conf.$interface.std ]; then
> if [ -f /etc/resolv.conf.tail ]; then
> - cat /etc/resolv.conf.tail >>/etc/resolv.conf.std
> + cat /etc/resolv.conf.tail
> >>/etc/resolv.conf.$interface.std
> fi
>
> # In case (e.g. during OpenBSD installs) /etc/resolv.conf
> @@ -133,10 +133,9 @@ add_new_resolv_conf() {
> # the new data in the correct location.
>
> if [ -f /etc/resolv.conf ]; then
> - cat /etc/resolv.conf > /etc/resolv.conf.save
> + cat /etc/resolv.conf > /etc/resolv.conf.$interface.save
> fi
> - cat /etc/resolv.conf.std > /etc/resolv.conf
> - rm -f /etc/resolv.conf.std
> + cat /etc/resolv.conf.$interface.std > /etc/resolv.conf
>
> # Try to ensure correct ownership and permissions.
> chown -RL root:wheel /etc/resolv.conf
> @@ -152,21 +151,21 @@ ip6_add_new_resolv_conf() {
> # Create resolv.conf when either $new_dhcp6_name_servers or
> # $new_dhcp6_domain_search are provided.
>
> - rm -f /etc/resolv.conf.std6
> + rm -f /etc/resolv.conf.$interface.std6
>
> if [ -n "$new_dhcp6_domain_search" ]; then
> - echo "search $new_dhcp6_domain_search" >>/etc/resolv.conf.std6
> + echo "search $new_dhcp6_domain_search"
> >>/etc/resolv.conf.$interface.std6
> fi
>
> if [ -n "$new_dhcp6_name_servers" ]; then
> for nameserver in $new_dhcp6_name_servers; do
> - echo "nameserver $nameserver" >>/etc/resolv.conf.std6
> + echo "nameserver $nameserver"
> >>/etc/resolv.conf.$interface.std6
> done
> fi
>
> - if [ -f /etc/resolv.conf.std6 ]; then
> + if [ -f /etc/resolv.conf.$interface.std6 ]; then
> if [ -f /etc/resolv.conf.tail ]; then
> - cat /etc/resolv.conf.tail >>/etc/resolv.conf.std6
> + cat /etc/resolv.conf.tail
> >>/etc/resolv.conf.$interface.std6
> fi
>
> # In case (e.g. during OpenBSD installs) /etc/resolv.conf
> @@ -174,10 +173,9 @@ ip6_add_new_resolv_conf() {
> # the new data in the correct location.
>
> if [ -f /etc/resolv.conf ]; then
> - cat /etc/resolv.conf > /etc/resolv.conf.save
> + cat /etc/resolv.conf > /etc/resolv.conf.$interface.save
> fi
> - cat /etc/resolv.conf.std6 > /etc/resolv.conf
> - rm -f /etc/resolv.conf.std6
> + cat /etc/resolv.conf.$interface.std6 > /etc/resolv.conf
>
> # Try to ensure correct ownership and permissions.
> chown -RL root:wheel /etc/resolv.conf
> @@ -256,8 +254,13 @@ EXPIRE|FAIL)
> fi
> # XXX Why add alias we just deleted above?
> add_new_alias
> - if [ -f /etc/resolv.conf.save ]; then
> - cat /etc/resolv.conf.save > /etc/resolv.conf
> + if [ -f /etc/resolv.conf.$interface.std ]; then
> + cmp -s /etc/resolv.conf /etc/resolv.conf.$interface.std
> + if [ $? -eq 0 -a -f /etc/resolv.conf.$interface.save ];
Re: ld.so fix for empty LD_PRELOAD
I kind of disagree with you mark and I think that the diff makes sense. On Fri, Dec 17, 2010 at 11:48:06AM +0100, Mark Kettenis wrote: > > Date: Thu, 16 Dec 2010 22:43:04 +0100 > > From: Stefan Sperling > > > > $ export LD_PRELOAD='' > > $ sed > > sed: can't load library '' > > $ env > > env: can't load library '' > > $ vim > > /usr/local/bin/vim: can't load library '' > > $ > > > > Is this the right way to fix it? > > I'd say it works just fine without your fix. If you really don't want > to preload stuff, make sure LD_PRELOAD isn't set at all. > > > Index: loader.c > > === > > RCS file: /cvs/src/libexec/ld.so/loader.c,v > > retrieving revision 1.120 > > diff -u -p -r1.120 loader.c > > --- loader.c25 Oct 2010 20:34:44 - 1.120 > > +++ loader.c16 Dec 2010 21:40:07 - > > @@ -493,7 +493,7 @@ _dl_boot(const char **argv, char **envp, > > TAILQ_INSERT_TAIL(&_dlopened_child_list, n, next_sib); > > exe_obj->opencount++; > > > > - if (_dl_preload != NULL) > > + if (_dl_preload != NULL && _dl_preload[0] != '\0') > > _dl_dopreload(_dl_preload); > > > > _dl_load_dep_libs(exe_obj, exe_obj->obj_flags, 1);
Re: Allegations regarding OpenBSD IPSEC
> On Thu, Dec 16, 2010 at 3:30 PM, Marc Espie 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. B Ever heard about FUD ? > > > > - of course OpenBSD is going to check. Geeez!! what do you think ? > > I'm really sorry to pitch in here, but... > > The centerpiece of this thread, besides technical details of how/whether to > prove/disprove the so-called accusations, seems to be an argument on > whether Perry's purely FUD'ing, promoting his company/pages, creating > the buzz, or whether his words should be taken for their face value. As for promoting his company, someone yesterday showed me this: http://www.sunbiz.org/scripts/ficidet.exe?action=DETREG&docnum=G09000158184&rdocnum=G09000158184 Look at the line marked Status. > I have to say that Perry here is credited with one thing he actually did not > do -- publish this to the world. There has been talk of alterior motives here, > but for any of these motives, Perry had to know or pretty damn well guessed > that the second thing Theo (hi, Theo) would do to his email was to publish > it. > Would you plan anything based on a predicted behavior of a person you > haven't communicated with in 10 years? > > This is not to point finger at Theo for creating all this commotion, of > course; > this commotion can, however, be, an unintended accident, but the fact that > it came from Theo gave it a lot of credibility. Whoa, wait a second here. If you think I gave it credibility, you need to go back and read my words again. I called it an allegation, and I stick with that. I was extremely careful with my words, and you are wrong to interpret them as you do.
Re: ld.so fix for empty LD_PRELOAD
> Date: Fri, 17 Dec 2010 08:21:05 -0600 > From: Marco Peereboom > > I kind of disagree with you mark and I think that the diff makes sense. FWIW, I feel too strongly about this. > On Fri, Dec 17, 2010 at 11:48:06AM +0100, Mark Kettenis wrote: > > > Date: Thu, 16 Dec 2010 22:43:04 +0100 > > > From: Stefan Sperling > > > > > > $ export LD_PRELOAD='' > > > $ sed > > > sed: can't load library '' > > > $ env > > > env: can't load library '' > > > $ vim > > > /usr/local/bin/vim: can't load library '' > > > $ > > > > > > Is this the right way to fix it? > > > > I'd say it works just fine without your fix. If you really don't want > > to preload stuff, make sure LD_PRELOAD isn't set at all. > > > > > Index: loader.c > > > === > > > RCS file: /cvs/src/libexec/ld.so/loader.c,v > > > retrieving revision 1.120 > > > diff -u -p -r1.120 loader.c > > > --- loader.c 25 Oct 2010 20:34:44 - 1.120 > > > +++ loader.c 16 Dec 2010 21:40:07 - > > > @@ -493,7 +493,7 @@ _dl_boot(const char **argv, char **envp, > > > TAILQ_INSERT_TAIL(&_dlopened_child_list, n, next_sib); > > > exe_obj->opencount++; > > > > > > - if (_dl_preload != NULL) > > > + if (_dl_preload != NULL && _dl_preload[0] != '\0') > > > _dl_dopreload(_dl_preload); > > > > > > _dl_load_dep_libs(exe_obj, exe_obj->obj_flags, 1);
Re: Allegations regarding OpenBSD IPSEC
On Fri, Dec 17, 2010 at 08:59:13AM -0700, Theo de Raadt wrote: > > This is not to point finger at Theo for creating all this commotion, of > > course; > > this commotion can, however, be, an unintended accident, but the fact that > > it came from Theo gave it a lot of credibility. > > Whoa, wait a second here. If you think I gave it credibility, you > need to go back and read my words again. I called it an allegation, > and I stick with that. I was extremely careful with my words, and you > are wrong to interpret them as you do. Theo, it's hopeless. Kids these days. Can't read, can't code. If you write anything, you can be certain they will take it out of context. They don't understand what a context is. Heck, they will use the excuse that they're "not native speakers" to say they misunderstood. I mean, why should they make the effort ? it's so easier to take a rumor out of context, not verify the source, not verify what it says and run with it. There's NEVER an excuse for mediocrity. I'm not a native speaker, Theo isn't either. That's not a good reason for not understanding/not writing english. That's the same with code, just because you learnt to program with a bad crowd is no excuse for most of the linux and java code out there. ;-)
Re: Allegations regarding OpenBSD IPSEC
On Fri, Dec 17, 2010 at 7:59 AM, Theo de Raadt wrote: [skipped] > > I have to say that Perry here is credited with one thing he actually did not > > do -- publish this to the world. There has been talk of alterior motives here, > > but for any of these motives, Perry had to know or pretty damn well guessed > > that B the second thing Theo (hi, Theo) would do to his email was to publish it. > > Would you plan anything based on a predicted behavior of a person you > > haven't communicated with in 10 years? > > > > This is not to point finger at Theo for creating all this commotion, of course; > > this commotion can, however, be, an unintended accident, but the fact that > > it came from Theo gave it a lot of credibility. > > Whoa, wait a second here. B If you think I gave it credibility, you > need to go back and read my words again. B I called it an allegation, > and I stick with that. B I was extremely careful with my words, and you > are wrong to interpret them as you do. Look, if somebody like me posted something like this here, it would be just plain dismissed. If Perry posted his email here, he'd just be under fire to show some or any proof. The reason this was so widely picked up and generated so much flame and buzz, is because you posted it here. It's an unfortunate consequence of a right action, really. I'm not even remotely saying that you intended to give it weight, or that you should've swept it under the rug.
Re: Allegations regarding OpenBSD IPSEC
> On Fri, Dec 17, 2010 at 7:59 AM, Theo de Raadt wr= > ote: > > [skipped] > > > > I have to say that Perry here is credited with one thing he actually di= > d not > > > do -- publish this to the world. There has been talk of alterior motive= > s here, > > > but for any of these motives, Perry had to know or pretty damn well gue= > ssed > > > that =C2=A0the second thing Theo (hi, Theo) would do to his email was t= > o publish it. > > > Would you plan anything based on a predicted behavior of a person you > > > haven't communicated with in 10 years? > > > > > > This is not to point finger at Theo for creating all this commotion, of= > course; > > > this commotion can, however, be, an unintended accident, but the fact t= > hat > > > it came from Theo gave it a lot of credibility. > > > > Whoa, wait a second here. =C2=A0If you think I gave it credibility, you > > need to go back and read my words again. =C2=A0I called it an allegation, > > and I stick with that. =C2=A0I was extremely careful with my words, and y= > ou > > are wrong to interpret them as you do. > > Look, if somebody like me posted something like this here, it would be just > plain dismissed. If that is the case -- that people would dismiss it automatically -- then the community is really stupid. You are almost arguing that that is the way it should be. Allegation of not, code should always be checked, and re-checked, and re-checked. What I am seeing is that we have a ridiculously upside-down trust model -- "Trust the developers". We never asked for people to trust us. We might have "earned some" in some people's eyes, but if so it has always been false, even before this. People should trust what they test, but the world has become incredibly lazy. We build this stuff by trusting each other as friends, and that is done on an international level. If anything, the layers and volume of trust involved in software development should decrease trust. Oh right, let's hear some of that "many eyes" crap again. My favorite part of the "many eyes" argument is how few bugs were found by the two eyes of Eric (the originator of the statement). All the many eyes are apparently attached to a lot of hands that type lots of words about many eyes, and never actually audit code. If anything, the collaborative model we use should _decrease_ trust, except, well, unless you compare it to the other model -- corporate software -- where they don't even start from any position of trust. There you are trusting the money, here you are trusting people I've never met. > If Perry posted his email here, he'd just be under fire to > show some or any proof. OK, so I post it, and then noone asks him for proof, now it suddenly has more strength? I am so bloody dissapointed in the community that uses our stuff. > The reason this was so widely picked up > and generated so much flame and buzz, is because you posted it here. How dismal. > It's an unfortunate consequence of a right action, really. I'm not even > remotely saying that you intended to give it weight, or that you > should've swept it under the rug. What a dismal world view.
Re: Allegations regarding OpenBSD IPSEC
Theo, this thread is DEAD. Drop it. No one believes in "backdoors" planted into OpenBSD. I se commits - you dig all over the place. If "backdoor" existed, then it is gone cause of this digging. Without proof its just a plain BS. P.S. I lost my interest for a while ago now. On Dec 17, 2010, at 7:23 PM, Theo de Raadt wrote: >> On Fri, Dec 17, 2010 at 7:59 AM, Theo de Raadt wr= >> ote: >> >> [skipped] >> I have to say that Perry here is credited with one thing he actually di= >> d not do -- publish this to the world. There has been talk of alterior motive= >> s here, but for any of these motives, Perry had to know or pretty damn well gue= >> ssed that =C2=A0the second thing Theo (hi, Theo) would do to his email was t= >> o publish it. Would you plan anything based on a predicted behavior of a person you haven't communicated with in 10 years? This is not to point finger at Theo for creating all this commotion, of= >> course; this commotion can, however, be, an unintended accident, but the fact t= >> hat it came from Theo gave it a lot of credibility. >>> >>> Whoa, wait a second here. =C2=A0If you think I gave it credibility, you >>> need to go back and read my words again. =C2=A0I called it an allegation, >>> and I stick with that. =C2=A0I was extremely careful with my words, and y= >> ou >>> are wrong to interpret them as you do. >> >> Look, if somebody like me posted something like this here, it would be just >> plain dismissed. > > If that is the case -- that people would dismiss it automatically -- > then the community is really stupid. You are almost arguing that that > is the way it should be. > > Allegation of not, code should always be checked, and re-checked, and > re-checked. > > What I am seeing is that we have a ridiculously upside-down trust > model -- "Trust the developers". > > We never asked for people to trust us. We might have "earned some" in > some people's eyes, but if so it has always been false, even before > this. People should trust what they test, but the world has become > incredibly lazy. > > We build this stuff by trusting each other as friends, and that is > done on an international level. If anything, the layers and volume of > trust involved in software development should decrease trust. Oh > right, let's hear some of that "many eyes" crap again. My favorite > part of the "many eyes" argument is how few bugs were found by the two > eyes of Eric (the originator of the statement). All the many eyes are > apparently attached to a lot of hands that type lots of words about > many eyes, and never actually audit code. > > If anything, the collaborative model we use should _decrease_ trust, > except, well, unless you compare it to the other model -- corporate > software -- where they don't even start from any position of trust. > There you are trusting the money, here you are trusting people I've > never met. > >> If Perry posted his email here, he'd just be under fire to >> show some or any proof. > > OK, so I post it, and then noone asks him for proof, now it suddenly > has more strength? I am so bloody dissapointed in the community that > uses our stuff. > >> The reason this was so widely picked up >> and generated so much flame and buzz, is because you posted it here. > > How dismal. > >> It's an unfortunate consequence of a right action, really. I'm not even >> remotely saying that you intended to give it weight, or that you >> should've swept it under the rug. > > What a dismal world view.
Re: Allegations regarding OpenBSD IPSEC
I agree with Marc - "it's hopeless" We live in a world where spin is king. Anything you say can and will be twisted against you. On 12/17/10 9:39 AM, Marc Espie wrote: On Fri, Dec 17, 2010 at 08:59:13AM -0700, Theo de Raadt wrote: This is not to point finger at Theo for creating all this commotion, of course; this commotion can, however, be, an unintended accident, but the fact that it came from Theo gave it a lot of credibility. Whoa, wait a second here. If you think I gave it credibility, you need to go back and read my words again. I called it an allegation, and I stick with that. I was extremely careful with my words, and you are wrong to interpret them as you do. Theo, it's hopeless. Kids these days. Can't read, can't code. If you write anything, you can be certain they will take it out of context. They don't understand what a context is. Heck, they will use the excuse that they're "not native speakers" to say they misunderstood. I mean, why should they make the effort ? it's so easier to take a rumor out of context, not verify the source, not verify what it says and run with it. There's NEVER an excuse for mediocrity. I'm not a native speaker, Theo isn't either. That's not a good reason for not understanding/not writing english. That's the same with code, just because you learnt to program with a bad crowd is no excuse for most of the linux and java code out there. ;-)
Re: multiple acpihpet devices
The reasoning versus changing acpihpet match function to reject duplicates and forcing acpihpet0 instead of acpihpet* in the kernel configuration file should really come down to this: - if acpihpet attaches to a bus which can be enumerated, then the kernel configuration file should contain `acpihpet*' and the matching code should behave correctly. - if acpihpet attaches to a bus which can not be enumerated, then it makes sense to move to an `acpihpet0' stanza in the kernel configuration file. Miod
Re: usb_{bulk,interrupt}_transfer() and PCATCH
On Sat, Dec 11, 2010 at 08:14:24PM +0100, Mark Kettenis wrote:
> Sorry, but this very much feels like you're hacking around a bug in
> the application you're using. If it installs signal handler without
> specifying the SA_RESTART flag, it has to deal with read(2) failing
> with EINTR.
after talking with ratchov and deraadt, I am convinced the bug is that
we have a read() interface that can be interrupted but not restarted
reliably. i.e. even if the application deals with EINTR, it's
not reliable because data is lost in the kernel.
so I took a shot at making ugen's read() interface restartable.
diff is below. unfortunately it only works about 90% of the time.
the original diff I sent works 100%. this diff is also a bit
complicated, and still requires complicated userland code to
deal with EINTR, because of timeouts. say you have a 4 second
timeout, and get interrupted after 3 seconds. so you restart with
a 4 second timeout, then get interrupted again, so you restart
... ad infinitum. otoh, you can gettimeofday and keep track
of how long you've been waiting, timersub and reset the timeout ...
but then you're potentially using a smaller timeout than is
required. this timeout mess is exactly where the 10% failure rate
comes from.
considering that
a) I can't find any code that expects EINTR in this case,
b) no other transfers in our usb code are interruptable,
c) doing the "right" thing is complicated both in the kernel and in
userland,
I am going to commit the original diff, minus the priority change.
I am just posting this here to let interested people know what the
situation is. I agree it would be nice/correct if it were possible to
interrupt and restart read(), but I also think it's more important
to have things actually work reliably.
--
jake...@sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org
Index: ugen.c
===
RCS file: /cvs/src/sys/dev/usb/ugen.c,v
retrieving revision 1.62
diff -u -p ugen.c
--- ugen.c 24 Sep 2010 08:33:59 - 1.62
+++ ugen.c 17 Dec 2010 12:29:23 -
@@ -84,6 +84,9 @@ struct ugen_endpoint {
u_char *limit; /* end of circular buffer (isoc) */
u_char *cur;/* current read location (isoc) */
u_int32_t timeout;
+ usbd_xfer_handle bulk_xfer;
+ int bulk_cb_pending;
+ usbd_status bulk_cb_status;
struct isoreq {
struct ugen_endpoint *sce;
usbd_xfer_handle xfer;
@@ -109,6 +112,7 @@ void ugenintr(usbd_xfer_handle xfer, usbd_private_hand
usbd_status status);
void ugen_isoc_rintr(usbd_xfer_handle xfer, usbd_private_handle addr,
usbd_status status);
+void ugen_bulk_read_cb(usbd_xfer_handle, usbd_private_handle, usbd_status);
int ugen_do_read(struct ugen_softc *, int, struct uio *, int);
int ugen_do_write(struct ugen_softc *, int, struct uio *, int);
int ugen_do_ioctl(struct ugen_softc *, int, u_long,
@@ -337,10 +341,20 @@ ugenopen(dev_t dev, int flag, int mode, struct proc *p
DPRINTFN(5, ("ugenopen: interrupt open done\n"));
break;
case UE_BULK:
+ sce->ibuf = malloc(UGEN_BBSIZE, M_USBDEV, M_WAITOK);
+ sce->cur = sce->fill = sce->ibuf;
+ sce->limit = sce->ibuf + UGEN_BBSIZE;
err = usbd_open_pipe(sce->iface,
edesc->bEndpointAddress, 0, &sce->pipeh);
- if (err)
+ if (err) {
+ free(sce->ibuf, M_USBDEV);
return (EIO);
+ }
+ sce->bulk_xfer = usbd_alloc_xfer(sc->sc_udev);
+ if (sce->bulk_xfer == 0) {
+ free(sce->ibuf, M_USBDEV);
+ return (ENOMEM);
+ }
break;
case UE_ISOCHRONOUS:
if (dir == OUT)
@@ -445,7 +459,14 @@ ugenclose(dev_t dev, int flag, int mode, struct proc *
case UE_ISOCHRONOUS:
for (i = 0; i < UGEN_NISOREQS; ++i)
usbd_free_xfer(sce->isoreqs[i].xfer);
-
+ break;
+ case UE_BULK:
+ while (sce->bulk_cb_pending)
+ tsleep(&sce->bulk_cb_pending, PZERO, "ugencb",
+ 0);
+ if (sce->bulk_xfer != NULL)
+ usbd_free_xfer(sce->bulk_xfer);
+ break;
default:
break;
}
@@ -465,8 +486,7 @@ int
ugen_do_read(struct ugen_softc *sc, int endpt, struct uio *uio, int flag)
{
struct ugen_endpoint *sce = &sc->sc_endpoints[
Re: ld.so fix for empty LD_PRELOAD
Mark Kettenis wrote: > > From: Marco Peereboom > > > > I kind of disagree with you mark and I think that the diff > > makes sense. > > FWIW, I feel too strongly about this. If you want to check it check it properly. For example use stat to see if LD_PRELOAD contains an existing file or use file to see if it's really a library. But checking if LD_PRELOAD only contains an empty string seems like a non check. Would you also check if it contained a space or two spaces? Actually there is no need to check since if the file is not a valid library the result would be an error which the user has to debug. Something about giving users enough rope... # Han
relayd: relay performance patch
The below patch is for those using relayd w/ the relay (not redirect)
function.
If you are seeing "Address already in use errors" with option -d or
performance issues with a lot of traffic, please test and report.
This disables SO_REUSEPORT on connect()'s.
Index: relay.c
===
RCS file: /cvs/src/usr.sbin/relayd/relay.c,v
retrieving revision 1.127
diff -u -p -r1.127 relay.c
--- relay.c 30 Nov 2010 14:49:14 - 1.127
+++ relay.c 17 Dec 2010 19:22:04 -
@@ -59,7 +59,7 @@ void relay_protodebug(struct relay *);
voidrelay_init(void);
voidrelay_launch(void);
int relay_socket(struct sockaddr_storage *, in_port_t,
- struct protocol *, int);
+ struct protocol *, int, int);
int relay_socket_listen(struct sockaddr_storage *, in_port_t,
struct protocol *);
int relay_socket_connect(struct sockaddr_storage *, in_port_t,
@@ -622,7 +622,7 @@ relay_socket_af(struct sockaddr_storage
int
relay_socket(struct sockaddr_storage *ss, in_port_t port,
-struct protocol *proto, int fd)
+struct protocol *proto, int fd, int reuseport)
{
int s = -1, val;
struct linger lng;
@@ -641,7 +641,9 @@ relay_socket(struct sockaddr_storage *ss
if (setsockopt(s, SOL_SOCKET, SO_LINGER, &lng, sizeof(lng)) == -1)
goto bad;
val = 1;
- if (setsockopt(s, SOL_SOCKET, SO_REUSEPORT, &val, sizeof(int)) == -1)
+ if (reuseport)
+ if (setsockopt(s, SOL_SOCKET, SO_REUSEPORT, &val,
+sizeof(int)) == -1)
goto bad;
if (fcntl(s, F_SETFL, O_NONBLOCK) == -1)
goto bad;
@@ -708,7 +710,7 @@ relay_socket_connect(struct sockaddr_sto
{
int s;
- if ((s = relay_socket(ss, port, proto, fd)) == -1)
+ if ((s = relay_socket(ss, port, proto, fd, 0)) == -1)
return (-1);
if (connect(s, (struct sockaddr *)ss, ss->ss_len) == -1) {
@@ -729,7 +731,7 @@ relay_socket_listen(struct sockaddr_stor
{
int s;
- if ((s = relay_socket(ss, port, proto, -1)) == -1)
+ if ((s = relay_socket(ss, port, proto, -1, 1)) == -1)
return (-1);
if (bind(s, (struct sockaddr *)ss, ss->ss_len) == -1)
Re: Allegations regarding OpenBSD IPSEC
On Fri, Dec 17, 2010 at 11:39 PM, Pawel Veselov wrote: > > > Whoa, wait a second here. B If you think I gave it credibility, you > > need to go back and read my words again. B I called it an allegation, > > and I stick with that. B I was extremely careful with my words, and you > > are wrong to interpret them as you do. > > Look, if somebody like me posted something like this here, it would be just > plain dismissed. > So it is good that Theo posted it here. He is serious about this allegation. Serious about proving if it is true or false. He has opened the invitation to any in order to acheive the objective. And he and others are dong the needful the outcome of which you will be able to see in a a couple or more of days. > If Perry posted his email here, he'd just be under fire to > show some or any proof. > Well may be Theo does not fell the urge to push away responsibility on others? Being the project leader he is doing just what a responsible and accountable person will do. >The reason this was so widely picked up > and generated so much flame and buzz, is because you posted it here. > So would you prefer he kept it secret? > It's an unfortunate consequence of a right action, really. I'm not even > remotely saying that you intended to give it weight, or that you > should've swept it under the rug. > Then waht are you tring to say? thanks --Siju
He get $219,249 Last Month
Works on ANY Computer Profiting 112 Minutes From NOW $4,191 In First 7 Days $219,249 Last Month Only 234 Copies Available - If You Don't Get Results, You'll Get A Full Refund AND $100 Join Now : http://business-page.us/change-your-life-become-rich.html
