Paul Vixie und bind
H. Gremming
was andere davon halten:
Subject: PRE-ANNOUNCEMENT: BIND-Members Forum
Date: Wed, 31 Jan 2001 09:36:02 -0800
From: Paul A Vixie <Paul_...@isc.org>
X-Approved-By: Ruth.An...@nominum.com
X-original-sender: Paul_...@ISC.Org
ISC has historically depended upon the "bind-workers" mailing list, and
CERT advisories, to notify vendors of potential or actual security flaws
in its BIND package. Recent events have very clearly shown that there is
a need for a fee-based membership forum consisting only of:
1. ISC itself
2. Vendors who include BIND in their products
3. Root and TLD name server operators
4. Other qualified parties (at ISC's discretion)
Requirements of bind-members will be:
1. Not-for-profit members can have their fees waived
2. Use of PGP (or possibly S/MIME) will be mandatory
3. Members will receive information security training
4. Members will sign strong nondisclosure agreements
Features and benefits of "bind-members" status will include:
1. Private access to the CVS pool where bind4, bind8 and bind9 live
2. Reception of early warnings of security or other important flaws
3. Periodic in-person meetings, probably at IETF's conference sites
4. Participation on the bind-members mailing list
und dann noch die Bitte, alles nötige umgehend in die
Wege zu leiten.
Ich finde das schon reichlich stark.
Security by Obscurity ?
Heinrich
--
http://felix2.2y.net/
W1...@lina.inka.de
> und dann noch die Bitte, alles nötige umgehend in die
> Wege zu leiten.
> Ich finde das schon reichlich stark.
Jo, jetzt wollen Sie auch noch Geld mit ihrer scheiss Software verdienen. Ich
bin schon stark am evaluieren von Alternative. Ich glaube pdnsd is für einen
Cache Only Server ganz gut.
djbdns hat ja leider ein kleines politisches Problem :)
Gruss
Bernd
Joerg Wendland
H. Gremming <bpa...@gmx.net> wrote:
>Kam heute in Bugtraq - und mich würde interessieren,
>was andere davon halten:
Noch ein Grund, endlich auf djbdns umzusteigen.
>Security by Obscurity ?
Die wollen halt, dass nur noch die User den peinlichen $BBOTW [1] zu
sehen bekommen, die dafuer Geld ausgeben. Die jeweiligen Admins habens
nicht besser verdient und die Manager findens richtig toll, weil nur
was viel Geld kostet ist auch richtig gut.
Gruss, Joerg
[1] Bind Bug of the Week
--
Freier Platz fuer Berarbeitungsvermerke, bitte nicht beschriften.
W1...@lina.inka.de
> nicht besser verdient und die Manager findens richtig toll, weil nur
> was viel Geld kostet ist auch richtig gut.
Und ausserdem wurden die meisten Bind bugs ja wohl eh nicht vom ISC
entdeckt/gemeldet sondern aus der community. Und die wird kaum die Geheimliste
benutzen wenn sie auf BugTraq einen Namen bekommen kann.
Trotzdem ist das echt hochnotpeinlich und an den symptomen herumgedoctort.
Gruss
Bernd
Rainer Weikusat
> 2. Reception of early warnings of security or other important flaws
Viel Erfolg :->
--
SIGSTOP
Ulrich Eckhardt
>
> Jo, jetzt wollen Sie auch noch Geld mit ihrer scheiss Software verdienen. Ich
> bin schon stark am evaluieren von Alternative. Ich glaube pdnsd is für einen
> Cache Only Server ganz gut.
>
> djbdns hat ja leider ein kleines politisches Problem :)
Hi,
ich habe mir gerade eben auch mal djbdns angeschaut. Aber abgesehen
davon, dass man das Teil als Distributor nur so installieren darf,
wie das default mässig in den sourcen eingestellt ist, habe ich
nichts merkwürdiges gefunden.
Habe ich da was übersehen ?
Uli
--
Ulrich Eckhardt Tr@nscom
http://www.uli-eckhardt.de http://www.transcom.de
Lagerstraße 11-15 A8
64807 Dieburg Germany
Felix von Leitner
> ich habe mir gerade eben auch mal djbdns angeschaut. Aber abgesehen
> davon, dass man das Teil als Distributor nur so installieren darf,
> wie das default mässig in den sourcen eingestellt ist, habe ich
> nichts merkwürdiges gefunden.
>
> Habe ich da was übersehen ?
Nein.
Ecki labert anderer Leute Kram nach, den schon diese nicht wirklich
verstanden haben.
An djbdns ist genau nichts auszusetzen.
Leute, die Software einsetzen, weil sie beim Betrübssystem mitgeliefert
waren, waren schon immer Idioten.
Felix
Tino Reichardt
>An djbdns ist genau nichts auszusetzen.
Es könnte GPL sein, das wäre schön :)
>Leute, die Software einsetzen, weil sie beim Betrübssystem mitgeliefert
>waren, waren schon immer Idioten.
Da hast du recht, aber kann man das nicht etwas besser ausdrücken ?
TR
Gerd Knorr
> Ulrich Eckhardt <Ulrich....@transcom.de> wrote:
> > ich habe mir gerade eben auch mal djbdns angeschaut. Aber abgesehen
> > davon, dass man das Teil als Distributor nur so installieren darf,
> > wie das default mässig in den sourcen eingestellt ist, habe ich
> > nichts merkwürdiges gefunden.
> >
> > Habe ich da was übersehen ?
>
> Nein.
>
Doch, für's Packaging ist die diese Regelung schon ein Hindernis.
Es steht übrigens auch drin daß man keine gepatchten binaries
ausliefern darf, was beispielsweise im Widerspruch zu den Debian
Spielregeln steht.
> Leute, die Software einsetzen, weil sie beim Betrübssystem mitgeliefert
> waren, waren schon immer Idioten.
Trotzdem wäre es schon nett wenn die dnstools einfach bei der Distribution
dabei liegen würden und man sie einfach nur installieren muß statt sie
auf jedem Rechner durchzubauen (oder eigene Pakete zu stricken). Einem
diese Arbeit abzunehmen ist ja genau der Zweck einer Distribution.
Gerd
--
document.write('<noscript> ... </noscript>');
-- gefunden in einem pixelpark flash banner
Martin Werthmoeller
>Felix von Leitner wrote:
>> Ulrich Eckhardt <Ulrich....@transcom.de> wrote:
>> > ich habe mir gerade eben auch mal djbdns angeschaut. Aber abgesehen
>> > davon, dass man das Teil als Distributor nur so installieren darf,
>> > wie das default mässig in den sourcen eingestellt ist, habe ich
>> > nichts merkwürdiges gefunden.
>> >
>> > Habe ich da was übersehen ?
>>
>> Nein.
>>
>> An djbdns ist genau nichts auszusetzen.
>
>Doch, für's Packaging ist die diese Regelung schon ein Hindernis.
>Es steht übrigens auch drin daß man keine gepatchten binaries
>ausliefern darf, was beispielsweise im Widerspruch zu den Debian
>Spielregeln steht.
>
steht. Hier werden bei Installation des Pakets die Quellen installiert,
gepacht (?) und compiliert.
tschau,
martin!
--
The social dynamics of the net are a direct consequence of the fact
that nobody has yet developed a Remote Strangulation Protocol.
Larry Wall
H. Gremming
> Felix von Leitner wrote:
> > Ulrich Eckhardt <Ulrich....@transcom.de> wrote:
> > > ich habe mir gerade eben auch mal djbdns angeschaut. Aber abgesehen
> > > davon, dass man das Teil als Distributor nur so installieren darf,
> > > wie das default mässig in den sourcen eingestellt ist, habe ich
> > > nichts merkwürdiges gefunden.
> > >
> > > Habe ich da was übersehen ?
> >
> > Nein.
> >
> > An djbdns ist genau nichts auszusetzen.
> dabei liegen würden und man sie einfach nur installieren muß statt sie
> auf jedem Rechner durchzubauen (oder eigene Pakete zu stricken). Einem
> diese Arbeit abzunehmen ist ja genau der Zweck einer Distribution.
You are permitted to distribute a precompiled djbdns package if
(kannst du aber selbst lesen: http://cr.yp.to/djbdns/dist.html)
Warum gibt eigentlich außer ihm niemand eine Sicherheits-Garantie ?
Heinrich
--
http://felix2.2y.net/
Michael Simon
>Kam heute in Bugtraq - und mich würde interessieren,
>was andere davon halten:
>
>Subject: PRE-ANNOUNCEMENT: BIND-Members Forum
>...
Hat womöglich damit etwas zu tun:
Bugtraq-Posting verursacht Angriffe auf NAI-Server
http://www.heise.de/newsticker/data/pab-02.02.01-000/
--
Sicherheit im Kabelnetzwerk
http://www.home.pages.at/heaven/sec.htm
Security for Cable Networks
http://www.dslreports.com/security/
Felix von Leitner
> >An djbdns ist genau nichts auszusetzen.
> Es könnte GPL sein, das wäre schön :)
Wieso?
Was würde es dir konkret bringen?
Du dürftest Binaries von modifizierten Versionen verbreiten.
Das ist für den Anwender egal, das ist nur für Leute wie SuSE
interessant, die sich so von der Konkurrenz abheben wollen.
> >Leute, die Software einsetzen, weil sie beim Betrübssystem mitgeliefert
> >waren, waren schon immer Idioten.
> Da hast du recht, aber kann man das nicht etwas besser ausdrücken?
Ich fand das ziemlich gut ausgedrückt.
Nicht zu wortreich aber trotzdem prägnant.
Felix
Felix von Leitner
> > An djbdns ist genau nichts auszusetzen.
> Doch, für's Packaging ist die diese Regelung schon ein Hindernis.
Huh?
Packaging?
Wieso willst du djbdns packagen?
Intern? Intern darfst du das packen und verteilen, aber du darfst
deine Binaries halt nicht an andere Leute verteilen und djbdns nennen.
Angesichts der Horden von Idioten-Anfragen auf der Mailingliste kann ich
das verstehen. djb hat keine Lust darauf, auf Anfragen mit
irgendwelchen KI-Shellscripten reagieren zu müssen, weil irgendwelche
Pfade bei irgendwelchen Distributionen anders sind.
> Es steht übrigens auch drin daß man keine gepatchten binaries
> ausliefern darf, was beispielsweise im Widerspruch zu den Debian
> Spielregeln steht.
Ja und?
Was interessiert das dich als DNS-Serverbetreiber?
> > Leute, die Software einsetzen, weil sie beim Betrübssystem mitgeliefert
> > waren, waren schon immer Idioten.
> Trotzdem wäre es schon nett wenn die dnstools einfach bei der Distribution
> dabei liegen würden und man sie einfach nur installieren muß statt sie
> auf jedem Rechner durchzubauen (oder eigene Pakete zu stricken). Einem
> diese Arbeit abzunehmen ist ja genau der Zweck einer Distribution.
Du kannst dir gerne selber Binärpakete von modifizierten Versionen
basteln und intern verteilen. Du darfst sie nur nicht ins Web hängen.
Das kann man auch prima automatisieren.
Felix
Felix von Leitner
> Warum gibt eigentlich außer ihm niemand eine Sicherheits-Garantie ?
Weil sich keiner sicher ist, daß sein Quellcode sicher ist.
Felix
Tino Reichardt
>> >An djbdns ist genau nichts auszusetzen.
>> Es könnte GPL sein, das wäre schön :)
>
>Wieso?
Auszug aus Deiner Seite:
[updated 010118] libowfat, an effort to reimplement libdjb under the
GPL.
>Was würde es dir konkret bringen?
Nix, ich kompiliere mir lieber (fast) alles selber, als irgendwelchen
Packeten zu vertrauen...
(und wenn ich mal ein Packet installiere, ist es eines von Slackware,
weil Patrick macht alles nach dem Motte "Keep it simple" - das gefällt
mir)
>Du dürftest Binaries von modifizierten Versionen verbreiten.
>Das ist für den Anwender egal, das ist nur für Leute wie SuSE
>interessant, die sich so von der Konkurrenz abheben wollen.
Leute wie die von Suse und RedHat haben zur Verbreitung von Linux sehr
viel beigetragen. Das sollte man nicht vergessen.
Das wir von ihren Ansichten, wie ein Linuxsystem aussehen sollte, nicht
viel halten, ist zweitrangig :)
>> Da hast du recht, aber kann man das nicht etwas besser ausdrücken?
>
>Ich fand das ziemlich gut ausgedrückt.
>Nicht zu wortreich aber trotzdem prägnant.
Ich meinte die Wortwahl.
TR
H. Gremming
> bpa...@gmx.net (H. Gremming) wrote:
>
> >Kam heute in Bugtraq - und mich würde interessieren,
> >was andere davon halten:
> >
> >Subject: PRE-ANNOUNCEMENT: BIND-Members Forum
> >...
>
> Hat womöglich damit etwas zu tun:
>
> Bugtraq-Posting verursacht Angriffe auf NAI-Server
> http://www.heise.de/newsticker/data/pab-02.02.01-000/
Nein, hat es nicht.
Paul Vixie hat mehrmals zu seinem Vorhaben Stellung genommen,
am besten liest du das selbst in Bugtraq nach
(falls englisch für dich kein zu großes Hindernis ist):
http://www.securityfocus.com/
dann Bugtraq, dann archive
Ich habe nichts weiter von Bugtraq kopiert,
weil ich annahm, das die meisten selbst nachsehen wollen.
Die Diskussion auf Bugtraq hat inzwischen auch einen
gewissen Umfang.
Heinrich
--
Felix von Leitner
> >> >An djbdns ist genau nichts auszusetzen.
> >> Es könnte GPL sein, das wäre schön :)
> >Wieso?
> Gegenfrage, wieso setzt du Deine Software lieber unter GPL:
> Auszug aus Deiner Seite:
>
> [updated 010118] libowfat, an effort to reimplement libdjb under the
> GPL.
Das ist eine Library, kein Softwarepaket.
> >Was würde es dir konkret bringen?
> Nix, ich kompiliere mir lieber (fast) alles selber, als irgendwelchen
> Packeten zu vertrauen...
Na also.
Alle möglichen Leute argumentieren immer mit irgendwelchen
hypothetischen anderen Leuten.
> >Du dürftest Binaries von modifizierten Versionen verbreiten.
> >Das ist für den Anwender egal, das ist nur für Leute wie SuSE
> >interessant, die sich so von der Konkurrenz abheben wollen.
> Leute wie die von Suse und RedHat haben zur Verbreitung von Linux sehr
> viel beigetragen. Das sollte man nicht vergessen.
Nein, das verzeihe^Wvergesse ich nicht.
Das hat uns die endlosen Fluten der Hirntoten beschert, die erwarten,
daß man ihnen kostenlos das Handbuch vorliest.
Felix
Tino Reichardt
gleich...
>Nein, das verzeihe^Wvergesse ich nicht.
>Das hat uns die endlosen Fluten der Hirntoten beschert, die erwarten,
>daß man ihnen kostenlos das Handbuch vorliest.
Es gibt genauso viele DAUS die in ihrer Windowsumgebung geblieben sind,
weil sie sich da mit regedit etc. auskennen :)
btw: Ich glaube wir kommen immer weiter vom Thema ab und lassen diese
Diskussion deshalb.
TR
Daniel Roesen
> Warum gibt eigentlich außer ihm niemand eine Sicherheits-Garantie ?
Weil sie albern ist und keinen interessiert? Wenn meine Server
gerootet werden habe ich groessere Probleme als mickrige $500.
Das ist so wie bei ISPs, die 100% Verfuegbarkeit garantieren. Denen
tut es nicht weh, wenn sie dem einen oder anderen Kunden halt mal
die Monatsmiete erlassen muessen.
"Bauernfaengerei" ist glaube ich der Begriff dafuer.
Daniel Roesen
> Jo, jetzt wollen Sie auch noch Geld mit ihrer scheiss Software
> verdienen.
ISC ist non-profit.
Robin S. Socha
>> Warum gibt eigentlich außer ihm niemand eine Sicherheits-Garantie ?
> Weil sie albern ist und keinen interessiert? Wenn meine Server
> gerootet werden habe ich groessere Probleme als mickrige $500.
> Das ist so wie bei ISPs, die 100% Verfuegbarkeit garantieren. Denen
> tut es nicht weh, wenn sie dem einen oder anderen Kunden halt mal die
> Monatsmiete erlassen muessen.
Das ist insofern anders, als die ISPs ein kommerzielles Interesse haben.
> "Bauernfaengerei" ist glaube ich der Begriff dafuer.
Ist es in der Tat, wenn solche Security Guarantees für den Fall gegeben
werden, dass Du eine black box rooten kannst. Der Fall liegt by djbdns
jedoch anders:
,----[ The djbdns security guarantee ]
| I offer $500 to the first person to publicly report a verifiable
| security hole in the latest version of djbdns.
|
| Examples of security holes:
| * Buffer overflows allowing attackers to take over DNS caches, such
| as the NXT bug in BIND before 8.2.2-P4 (1999).
| * Buffer overflows allowing attackers to take over DNS servers,
| such as the IQUERY bug in BIND before 8.1.2-T3B (1998).
| * Buffer overflows allowing attackers to take over DNS clients.
| * Buffer overflows allowing attackers to take over DNS utilities.
|
| Bugs outside of djbdns, such as OS bugs or browser bugs, do not
| qualify. The vulnerability of DNS to forgery does not
| qualify. Denial-of-service attacks do not qualify. (An attacker can
| easily take down the Domain Name System, or selected parts of it;
| this is not news.)
|
| My judgment is final as to what constitutes a security hole in
| djbdns. Any disputes will be reported here.
`----
Tatsächlich ist hier die angebotene Summe wohl nebensächlich. Was zählt,
ist, dass eine Privatperson so großes Vertrauen in die Sicherheits ihres
Programms hat, dass sie eine Belohnung aus ihrem Privatvermögen für den
Fall bietet, dass Du eine Sicherheitslücke findest. Man kann das
angeberisch finden - Bauernfängerei ist es sicherlich nicht.
Bauernfängerei betreiben die verschiedenen kommerziellen
Hersteller, die "hacking contests" betreiben, indem sie eine Kiste
irgendwo im Netz aufstellen und sagen "wenn Du innert 3 Tagen hier
einbrechen kannst, kriegst Du das Geld" und dann damit Werbung für ihr
kommerzielles Produkt machen. Es muss wohl nicht betont werden, dass
neben dieser Kiste 20 schwitzende Mitarbeiter sitzen, die permanent die
logs bewachen und im Zweifelsfall aktiv eingreifen, wenn Probleme
auftauchen. Bei djbdns geht es darum, Fehler in einem offenen Source zu
finden. Ich sehe darin einen deutlichen Unterschied. Du nicht?
--
Robin S. Socha <http://socha.net/>
"The new glue is, unfortunately, ignored by recent versions of the BIND
cache; the detailed technical explanation for this is that the BIND
company is a bunch of idiots." (DJB)
Felix von Leitner
> > Jo, jetzt wollen Sie auch noch Geld mit ihrer scheiss Software
> > verdienen.
> ISC ist non-profit.
Ein Glück, daß Herr Roesen mal wieder in vollem Umfang informiert ist,
bevor er Müll postet...
Hier ist, was djb dazu schreibt:
Date: 2 Feb 2001 08:48:25 -0000
From: "D. J. Bernstein" <d...@cr.yp.to>
To: d...@list.cr.yp.to
Subject: Re: An Open Plea to D. J. Bernstein and DJBDNS Developers
Jim Breton writes:
> Anyway, one of the other stated concerns is, "What if he decides to go
> commercial?"
What if BIND decides to go commercial?
The Vixie cluster of companies---Vixie Enterprises, Nominum, Vayusphere,
PAIX, M.I.B.H. (swalloed by Metromedia), etc.---is already doing its
best to make money off BIND. They give us configuration problems and
then sell support services; they give us reliability problems and then
sell backup services; they give us security problems and then sell early
access to security information.
The natural next step is for them to start selling a BIND Pro with early
access to features and bug fixes that'll be added someday to the free
BIND. BIND isn't under the GPL, so there's no legal obstacle to this.
---Dan
Felix von Leitner
> > Warum gibt eigentlich außer ihm niemand eine Sicherheits-Garantie ?
> Weil sie albern ist und keinen interessiert? Wenn meine Server
> gerootet werden habe ich groessere Probleme als mickrige $500.
>
> Das ist so wie bei ISPs, die 100% Verfuegbarkeit garantieren. Denen
> tut es nicht weh, wenn sie dem einen oder anderen Kunden halt mal
> die Monatsmiete erlassen muessen.
Ah, Herr Rösen postet wieder Scheiße!
Fall jemand auf diese billige Rhetorik reingefallen ist: djb macht
keine Kohle mit seiner Software. Er zahlt die $500 also aus eigener
Tasche, von seinem mickrigen Gehalt als Professor.
Das ist natürlich nicht damit vergleichbar, ob ein ISP Geld erläßt, weil
djb schon vorher Verlust macht mit seiner Software, auch wenn er die
$500 nicht zahlt.
Daniel: nicht labern, handeln. Schau dir den Quellcode an und höre auf
hier diesen unerträglichen Müll von dir zu geben. Oder setze um Himmels
Willen weiter BIND ein und belästige uns nicht weiter.
Felix
Marc Haber
>You are permitted to distribute a precompiled djbdns package if
>(kannst du aber selbst lesen: http://cr.yp.to/djbdns/dist.html)
ja, Du darfst aber die Pfade nicht ändern. Und da djb's Auswahl der
Installationspfade diplomatisch ausgedrückt etwas eigenwillig (und
keinesfalls FHS compliant) ist, und manche Distributionen
sinnvollerweise in ihrer Policy niedergeschrieben haben, dass man sich
an den FHS halten will...
>Warum gibt eigentlich außer ihm niemand eine Sicherheits-Garantie ?
Weil er offensichtlich davon überzeugt ist, kein Mensch zu sein. Er
ist ein hervorragender Entwickler mit einem sehr großen Ego und glaubt
nicht daran, Fehler zu machen.
Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
Florian Weimer
> Ich finde das schon reichlich stark. Security by Obscurity ?
Im Prinzip läuft das doch auch schon heute so ab. UNIX-Vendors und
Root-Name-Server-Operators werden frühzeitig benachrichtigt. Neu wäre
nur, daß das ganze institutionalisiert würde und man als glaubwürdiger
und zahlungskräftiger Partner eine Chance hätte, aufgenommen zu
werden, falls man ein ISP o.ä. ist.
Es ist natürlich völlig unklug, dies in dieser Form anzukündigen. Man
könnte das auch als 'BIND Forum' bekanntgeben und dann im Stillen
werkeln. ;-)
Dietz Proepper
>bpa...@gmx.net (H. Gremming) writes:
>
>> Ich finde das schon reichlich stark. Security by Obscurity ?
>
>Im Prinzip läuft das doch auch schon heute so ab. UNIX-Vendors und
>Root-Name-Server-Operators werden frühzeitig benachrichtigt. Neu wäre
Und werden von Company A Patches zurückgehalten um Company B die Zeit
zur Entwicklung eigener zu geben? Auch wenn Company B sich Zeit läßt?
>nur, daß das ganze institutionalisiert würde und man als glaubwürdiger
>und zahlungskräftiger Partner eine Chance hätte, aufgenommen zu
>werden, falls man ein ISP o.ä. ist.
Ähm. Du hast das NDA vergessen.
>Es ist natürlich völlig unklug, dies in dieser Form anzukündigen. Man
>könnte das auch als 'BIND Forum' bekanntgeben und dann im Stillen
>werkeln. ;-)
Ja, gegen Herrenrunden kann man nix tun ;)
Wobei's jemand auf bt sehr schön gesagt hat, wenn das (werdende?) Forum
einen Patch erst 3 Tage nach seiner Existenz veröffentlicht und Dritten
durch die Späterveröffentlichung Schaden entsteht dann wäre es gute Ami-
tradition, das Forum juristisch zurch den Kakao zu ziehen.
Dietz
Daniel Roesen
> > ISC ist non-profit.
>
> Ein Glück, daß Herr Roesen mal wieder in vollem Umfang informiert ist,
> bevor er Müll postet...
Meine Aussage ist Umfang korrekt. Auch wenn du das nicht wahrhaben
willst.
> They give us configuration problems and then sell support services;
Habe noch keine Konfigurationsprobleme gehabt, bei denen ich Support
einkaufen haette muessen.
> they give us reliability problems and then sell backup services;
Auch diese Stabilitaetsprobleme sind ein Urban Myth. Aber diesen
FUD ist man von DJB ja gewoehnt.
> they give us security problems and then sell early access to security
> information.
Ich wuesste nicht, dass der aktuelle BIND-Train (9) jemals ein
Sicherheitsproblem gehabt haette. Und DJBs Darstellung dessen was
Vixie vorgeschlagen hat ist mal wieder typisch verzerrend.
> The natural next step is for them to start selling a BIND Pro with early
> access to features and bug fixes that'll be added someday to the free
> BIND. BIND isn't under the GPL, so there's no legal obstacle to this.
Falsch. ISC muss als non-profit Gesellschaft BIND open-source anbieten.
Sie duerfen es garnicht anders.
Aber was hinder DJB daran, einfach seine Lizenz zu aendern? Niemand.
DJB soll erstmal nen vollwertigen DNS-Server auf die Beine stellen,
und dann kann rumplaerren.
Florian Weimer
> Und werden von Company A Patches zurückgehalten um Company B die Zeit
> zur Entwicklung eigener zu geben?
Ja, so ist zum Beispiel die Policy des CERT/CC.
> Auch wenn Company B sich Zeit läßt?
B kann sich recht viel Zeit lassen, wenn auch seit einigen Änderungen
beim CERT/CC nicht mehr beliebig lange (früher war das anders).
> >nur, daß das ganze institutionalisiert würde und man als glaubwürdiger
> >und zahlungskräftiger Partner eine Chance hätte, aufgenommen zu
> >werden, falls man ein ISP o.ä. ist.
>
> Ähm. Du hast das NDA vergessen.
Ja, und? Das existiert heutzutage wohl de facto als gentlemen agreement.
> Wobei's jemand auf bt sehr schön gesagt hat, wenn das (werdende?) Forum
> einen Patch erst 3 Tage nach seiner Existenz veröffentlicht und Dritten
> durch die Späterveröffentlichung Schaden entsteht dann wäre es gute Ami-
> tradition, das Forum juristisch zurch den Kakao zu ziehen.
Glaube ich nicht. Es ist ausgesprochen üblich, daß Security-Patches
bzw. der Bekanntgabe zurückgehalten werden, und noch hat AFAIK niemand
deswegen prozessiert, auch wenn ihm dadurch Nachteile entstanden sind.
W1...@lina.inka.de
> DJB soll erstmal nen vollwertigen DNS-Server auf die Beine stellen,
> und dann kann rumplaerren.
Was fehlt die denn in seinem?
Gruss
Bernd
Dietz Proepper
>> Und werden von Company A Patches zurückgehalten um Company B die Zeit
>> zur Entwicklung eigener zu geben?
>
>Ja, so ist zum Beispiel die Policy des CERT/CC.
So halten das Gentlemen normalerweise.
>> Auch wenn Company B sich Zeit läßt?
>
>B kann sich recht viel Zeit lassen, wenn auch seit einigen Änderungen
>beim CERT/CC nicht mehr beliebig lange (früher war das anders).
Und da beginnen imo Gentlemen nach endlicher Zeit u.U. stärker
Druck auszuüben.
>> >nur, daß das ganze institutionalisiert würde und man als glaubwürdiger
>> >und zahlungskräftiger Partner eine Chance hätte, aufgenommen zu
>> >werden, falls man ein ISP o.ä. ist.
>>
>> Ähm. Du hast das NDA vergessen.
>
>Ja, und? Das existiert heutzutage wohl de facto als gentlemen agreement.
Der wesentliche Unterschied - mit NDA ist man meist wesentlich stärker
der Möglichkeit beraubt, das agreement unter zwingenden Umständen zu
kündigen.
Nur als hypothetische Situation - Du bist bind-Club-Mitglied, Du entdeckst
ein böses Loch, meldest es der Clubleitung und die lassen sich Zeit.
Was würdest Du tun wenn Du Belege bekommst daß der exploit inzwischen
von Dritten entdeckt und verwendet wird und die Clubleitung weiter nicht
veröffentlicht?
>> Wobei's jemand auf bt sehr schön gesagt hat, wenn das (werdende?) Forum
>> einen Patch erst 3 Tage nach seiner Existenz veröffentlicht und Dritten
>> durch die Späterveröffentlichung Schaden entsteht dann wäre es gute Ami-
>> tradition, das Forum juristisch zurch den Kakao zu ziehen.
>
>Glaube ich nicht. Es ist ausgesprochen üblich, daß Security-Patches
>bzw. der Bekanntgabe zurückgehalten werden, und noch hat AFAIK niemand
>deswegen prozessiert, auch wenn ihm dadurch Nachteile entstanden sind.
In der Form daß $FIRMA ein derartiges Sicherheitsforum einrichtet?
Abgesehen davon, hierzulande sicher nicht aber in Amiland muß man
doch nur 'paar Geschworene überzeugen. Oder sehe ich zuviel fern? ;)
Naja, man wird sehen wie's sich entwickelt, im Spezialfall bind stört's
mich auch nicht wirklich. Nur sieht die pessimistische Projektion wenn
sich die Idee ausbreitet imo nicht so doll aus.
Dietz
Daniel Roesen
> > DJB soll erstmal nen vollwertigen DNS-Server auf die Beine stellen,
> > und dann kann rumplaerren.
>
> Was fehlt die denn in seinem?
DNS NOTIFY, DNS UPDATE, Slave-Verhalten gemaesst SOA, IPv6 RRs,
DNSSEC, forwarding-Domains. Und als Caching Resolver fehlt ihm
ein Forwarding.
Und nein, es komme mir bitte keiner mit rsync-over-ssh und cronjobs.
Felix von Leitner
> > > ISC ist non-profit.
> > Ein Glück, daß Herr Roesen mal wieder in vollem Umfang informiert ist,
> > bevor er Müll postet...
> Meine Aussage ist Umfang korrekt. Auch wenn du das nicht wahrhaben
> willst.
Ich habe nicht bestritten, daß ISC "non-profit" ist.
Wenn du mal genau hinschaust, wirst du feststellen, daß BIND9 nicht von
ISC programmiert wurde. ISC dient nur als Mäntelchen, damit ihnen
auf den ersten Blick keine Kommerz-Schweinereien vorzuwerfen sind.
Tatsächlich hat eine weitere Vixie-Company BIND9 implementiert: Nominum.
> > They give us configuration problems and then sell support services;
> Habe noch keine Konfigurationsprobleme gehabt, bei denen ich Support
> einkaufen haette muessen.
Wir verbeugen uns vor deiner Großartigkeit, Daniel.
> > they give us reliability problems and then sell backup services;
> Auch diese Stabilitaetsprobleme sind ein Urban Myth. Aber diesen
> FUD ist man von DJB ja gewoehnt.
Selbst mir, auf meiner Stink-Normal-1CPU-Linux 2.2 Box mit
Only-Stable-Versions Userland mit vier Pissels-Domains und einer
Handvoll DNS-Anfragen pro Tag, ist BIND 8.2.2 plus Security Patches of
the day alle 14+rand()%7 Tage abgeraucht. Regelmäßig. Ohne warnende
Logmeldungen. Einfach so. djbdns hat auf der gleichen Kiste mit den
gleichen Daten eine Uptime von über einem halben Jahr. Und verbraucht
ein 100stel des Hauptspeichers (und das meine ich wörtlich!).
> > they give us security problems and then sell early access to security
> > information.
> Ich wuesste nicht, dass der aktuelle BIND-Train (9) jemals ein
> Sicherheitsproblem gehabt haette.
Das liegt vielleicht an deiner üblichen Uninformiertheit?
Vielleicht läßt du dich ja doch eines Tages überzeugen, vor dem Posten
dein Gehirn zu aktivieren oder das Posten vielleicht sogar ganz
einzustellen?
629. [bug] 9.1.0b1 dereferenced a null pointer and crashed
when responding to a UDP IXFR request.
538. [bug] fix buffer overruns by 1 in lwres_getnameinfo().
245. [bug] If an uncompressed name will take more than 255
bytes and the buffer is sufficiently long,
dns_name_fromwire should return DNS_R_FORMERR,
not ISC_R_NOSPACE. This bug caused cause the
server to catch an assertion failure when it
received a query for a name longer than 255
bytes.
13. [bug] lib/dns/master.c and lib/dns/xfrin.c didn't ignore
out-of-zone data.
Nur so als Auszug.
Ach ja, erstaunlich ist auch die Anzahl der Cleanups, die in einem
angeblich "clean rewrite from scratch" nötig waren:
$ grep cleanup CHANGES | wc -l
109
$
Das sind die BIND 9 Sourcen, wo CHANGES überhaupt erst seit 9.0.0b2
mitloggt.
> Und DJBs Darstellung dessen was Vixie vorgeschlagen hat ist mal wieder
> typisch verzerrend.
Kannst du deine Bewertungen nicht einfach auf einen Zeitpunkt
verschieben, wo du die Materien rudimentär verstanden hast, von der du
redest?
BIND verkauft jetzt early access für Bugs und Bug-Fixes gegen Geld an
ausgewähltes Publikum. Man beachte, daß da nicht stand, daß jeder
subscriben darf, wenn er nur Geld zahlt. Nein, da standen Bedingungen,
die potentielle Kunden erfüllen müssen.
Paul Vixie hat gemerkt, daß die ganzen Versager auf der Welt von ihm
abhängig sind, und versucht da jetzt einen Hebel anzusetzen. Das ist
selber für Paul Vixie's Verhältnisse sehr schäbig.
> > The natural next step is for them to start selling a BIND Pro with early
> > access to features and bug fixes that'll be added someday to the free
> > BIND. BIND isn't under the GPL, so there's no legal obstacle to this.
> Falsch. ISC muss als non-profit Gesellschaft BIND open-source anbieten.
> Sie duerfen es garnicht anders.
Du warst dir doch wirklich nicht zu schäbig, die relevanten Teile
wegzulassen? Willst du dich jetzt Herrn Vixie annähern?
Dan sprach von dem "Vixie Cluster" von For-Profit Companies, nicht von
ISC.
> Aber was hinder DJB daran, einfach seine Lizenz zu aendern? Niemand.
Ja und? Wen betrifft das? Niemanden.
Und wieder labert Herr Rösen uninformierte Scheiße im Usenet.
ARGH! Wird dir das nicht irgendwann zu dämlich, dich so zum Trottel zu
machen?
Wenn Dan dir einmal eine Software zur Verfügung gestellt hat, kann er
dir im Nachhinein keine Rechte nehmen. Das nennt sich im US-Recht
"Waiver" und sieht in Deutschland ähnlich aus. Wenn du das heute
downloadest und er morgen seine Lizenz ändert, betrifft deine Version
das genau gar nicht. Nur zukünftige Versionen kann er unter eine andere
Lizenz stellen.
> DJB soll erstmal nen vollwertigen DNS-Server auf die Beine stellen,
> und dann kann rumplaerren.
Ah, eine gehörige Portion FUD rundet natürlich sogar derart abstoßende
Müllpostings wie deines hier negativ nach unten ab.
Du hast gerade das das Niveau von Kooks wie Frank Werner und Lars
Kaehler deutlich nach unten durchschlagen. Die tun wenigstens nicht so,
als wüßten sie, wovon sie sprechen.
Felix
--
Given the same load, BIND will chew up all your physical memory, start
thrashing, chew up all your virtual memory, and then commit hara-kiri,
if it doesn't dump core first.
--Dan Bernstein
Felix von Leitner
> >You are permitted to distribute a precompiled djbdns package if
> >(kannst du aber selbst lesen: http://cr.yp.to/djbdns/dist.html)
> ja, Du darfst aber die Pfade nicht ändern. Und da djb's Auswahl der
> Installationspfade diplomatisch ausgedrückt etwas eigenwillig (und
> keinesfalls FHS compliant) ist, und manche Distributionen
> sinnvollerweise in ihrer Policy niedergeschrieben haben, dass man sich
> an den FHS halten will...
Wen interessiert denn der FHS?
Überhaupt verstehe ich diese Binärpaket-Diskussion etwas.
Wollen wir hier ernsthaft über "Administratoren" diskutieren, die einen
DNS-Server einrichten können sollen, aber ohne Binärpaket nicht in der
Lage sind, "make; sudo make setup" zu tippen?!
Ich finde es ein _Feature_, daß es keine Binärpakete gibt.
Idioten, die Software, die nicht als RPM kommt, nicht installieren
können, sollen lieber bei Exchange und Active Directory bleiben und
damit untergehen.
> >Warum gibt eigentlich außer ihm niemand eine Sicherheits-Garantie ?
> Weil er offensichtlich davon überzeugt ist, kein Mensch zu sein. Er
> ist ein hervorragender Entwickler mit einem sehr großen Ego und glaubt
> nicht daran, Fehler zu machen.
Wenn du das Gegenteil beweisen kannst, wird er dir 500 Dollar auszahlen.
Ansonsten halte doch einfach die Klappe, OK? Danke.
Felix
Felix von Leitner
> > Und werden von Company A Patches zurückgehalten um Company B die Zeit
> > zur Entwicklung eigener zu geben?
> Ja, so ist zum Beispiel die Policy des CERT/CC.
Nein, das _Advisory_ wird zurückgehalten.
Nicht die Patches.
Aus den OpenBSD CVS-Meldungen kann man z.B. manchmal Security-Fixes
sehen, bevor das Problem von CERT durchgekaut ist. So dämlich, den
Vendors das Releasen von Patches zu verbieten, ist selbst CERT nicht.
Felix
Robin S. Socha
>> You are permitted to distribute a precompiled djbdns package if
>> (kannst du aber selbst lesen: http://cr.yp.to/djbdns/dist.html)
> ja, Du darfst aber die Pfade nicht ändern.
/Er/ darf die Pfade selbstverständlich ändern. Es dürfen nur keine
kompilierten Binaries mit anderen Pfaden verteilt werden. Es spricht
aber nichts gegen SRPMs oder ports.
> Und da djb's Auswahl der Installationspfade diplomatisch ausgedrückt
> etwas eigenwillig (und keinesfalls FHS compliant) ist,
Sie sind aber ausgezeichnet begründet.
> und manche Distributionen sinnvollerweise in ihrer Policy
> niedergeschrieben haben, dass man sich an den FHS halten will...
Klar, z.B. Su"/usr/sbin"SE. Weia...
>> Warum gibt eigentlich außer ihm niemand eine Sicherheits-Garantie ?
> Weil er offensichtlich davon überzeugt ist, kein Mensch zu sein.
Interessante Logik.
> Er ist ein hervorragender Entwickler mit einem sehr großen Ego und
> glaubt nicht daran, Fehler zu machen.
Korrekter: er glaubt nicht, dass Du oder jemand anders in seiner Software
Fehler finden wird. Und wenn ich mir den track record qmail/sendmail,
djbdns/BIND, tcpserver/inetd, ezmlm/majordomo ansehe, dann kann er sich
das bequem leisten.
Rainer Weikusat
> > DJB soll erstmal nen vollwertigen DNS-Server auf die Beine stellen,
> > und dann kann rumplaerren.
>
> Ah, eine gehörige Portion FUD rundet natürlich sogar derart abstoßende
> Müllpostings wie deines hier negativ nach unten ab.
DNS soll distributed caching machen.
--
SIGSTOP
Martin Werthmoeller
>
>DJB soll erstmal nen vollwertigen DNS-Server auf die Beine stellen,
>und dann kann rumplaerren.
>
hier nicht passt, geh' doch nach drüben" abzubügeln löst die Probleme auch
nicht.
Zugegeben, DJB hat eine große Klappe und polarisiert damit schnell.
tschau,
martin!
--
The social dynamics of the net are a direct consequence of the fact
that nobody has yet developed a Remote Strangulation Protocol.
Larry Wall
Rainer Weikusat
Leute, die über 'abandoned months ago'-Systeme stolpern und sich
wünschten, jemand anderes hätte auch schon mal davon gehört?
> Wenn du das Gegenteil beweisen kannst, wird er dir 500 Dollar
> auszahlen.
"Currently, dnscache supports four levels of gluelessness. Will this
be enough?"
Why do you ask?
--
SIGSTOP
Florian Weimer
> Florian Weimer <f...@deneb.enyo.de> wrote:
> > > Und werden von Company A Patches zurückgehalten um Company B die Zeit
> > > zur Entwicklung eigener zu geben?
> > Ja, so ist zum Beispiel die Policy des CERT/CC.
>
> Nein, das _Advisory_ wird zurückgehalten. Nicht die Patches.
Kannst Du mir einen Fall nennen, in dem ein Vendor ein Patch für ein
Problem ankündigte, das von CERT/CC noch beackert wurde? AFAIK gibt
es höchstens 'silent fixes', und das ist in der Praxis wenig
hilfreich.
> Aus den OpenBSD CVS-Meldungen kann man z.B. manchmal Security-Fixes
> sehen, bevor das Problem von CERT durchgekaut ist. So dämlich, den
> Vendors das Releasen von Patches zu verbieten, ist selbst CERT nicht.
Das ist ein Nebeneffekt des offenen Entwicklungsprozesses.
Philipp Buehler
<usenet-...@fefe.de> wrote:
>> Ich wuesste nicht, dass der aktuelle BIND-Train (9) jemals ein
>> Sicherheitsproblem gehabt haette.
>
>Das liegt vielleicht an deiner üblichen Uninformiertheit?
>Vielleicht läßt du dich ja doch eines Tages überzeugen, vor dem Posten
>dein Gehirn zu aktivieren oder das Posten vielleicht sogar ganz
>einzustellen?
> 629. [bug] 9.1.0b1 dereferenced a null pointer and crashed
> when responding to a UDP IXFR request.
Les ich da ein 'b' in der Version? Beta ist zum testen da.
Fehler macht jeder. Dafuer testet man. Wer beta-software 'draussen' einsetzt,
muss damit leben. Btw, um *den* bug zu nutzen, muss das setup vom admin
schon selten bloed aufgesetzt sein.
>Nur so als Auszug.
Genau, wir nehmen jetzt alle Fehler, die bei Tests aufgetreten sind als
security threat an. Schick.
>Ach ja, erstaunlich ist auch die Anzahl der Cleanups, die in einem
>angeblich "clean rewrite from scratch" nötig waren:
Man kann auch scratch code wieder cleanen.
Die Aussage bezieht sich auf die Wiederverwertung von code aus BINDv8.
DJB schreibt wohl alle code bloecke sofort sauber und ohne Fehler?
Wenn er das projezieren koennte, haett ich den gern als Kanzler.
>BIND verkauft jetzt early access für Bugs und Bug-Fixes gegen Geld an
>ausgewähltes Publikum. Man beachte, daß da nicht stand, daß jeder
>subscriben darf, wenn er nur Geld zahlt. Nein, da standen Bedingungen,
>die potentielle Kunden erfüllen müssen.
Lies mal die FAQ, die Paul auf bind-announce gepostet hat.
ciao
--
Philipp Buehler, aka fIpS | sysfive.com GmbH | BOfH | NUCH | <double-p>
#1: We are Luser of Borg...<whine> the assimilator doesn't wooooork </whine>
#2: Already had buzzword confuseritis ?
Alexander Schreiber
>> >An djbdns ist genau nichts auszusetzen.
>> Es könnte GPL sein, das wäre schön :)
>
>Wieso?
>Das ist für den Anwender egal, das ist nur für Leute wie SuSE
>interessant, die sich so von der Konkurrenz abheben wollen.
Hoer mir mit denen auf. Deren beste Leistung in der Beziehung war eine
Demo-CD mit SuSE-gepatchtem 2.2.17 Kernel, der beim Verwenden von Software-
Raid gecrasht ist. Standard 2.2.17 lief auf Anhieb.
Man liest sich,
Alex.
--
------------------------------------------------------------------------------
EMail : a...@thangorodrim.de | WWW : http://www.thangorodrim.de/
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison
Alexander Schreiber
>Felix von Leitner wrote:
>> Ulrich Eckhardt <Ulrich....@transcom.de> wrote:
>> > ich habe mir gerade eben auch mal djbdns angeschaut. Aber abgesehen
>> > davon, dass man das Teil als Distributor nur so installieren darf,
>> > wie das default mässig in den sourcen eingestellt ist, habe ich
>> > nichts merkwürdiges gefunden.
>> >
>> > Habe ich da was übersehen ?
>>
>> Nein.
>>
>> An djbdns ist genau nichts auszusetzen.
>
>Es steht übrigens auch drin daß man keine gepatchten binaries
>ausliefern darf, was beispielsweise im Widerspruch zu den Debian
>Spielregeln steht.
Na und? Dann liefert man halt die Sourcen + entsprechenden Patch aus und
baut das dann bei der Installation live zusammen (patchen, compilieren,
lokales Binaerpaket bauen, installieren). Das macht *BSD schon eine ganze
Weile so (ports) und Debian macht das bei einigen Packages auch so.
>> Leute, die Software einsetzen, weil sie beim Betrübssystem mitgeliefert
>> waren, waren schon immer Idioten.
>
>Trotzdem wäre es schon nett wenn die dnstools einfach bei der Distribution
>dabei liegen würden und man sie einfach nur installieren muß statt sie
>auf jedem Rechner durchzubauen (oder eigene Pakete zu stricken). Einem
>diese Arbeit abzunehmen ist ja genau der Zweck einer Distribution.
S.o. Als UNIX-Admin kann man entweder eigenstaendig denken und handeln
oder ist fehl am Platze.
Felix von Leitner
> > > DJB soll erstmal nen vollwertigen DNS-Server auf die Beine stellen,
> > > und dann kann rumplaerren.
> > Ah, eine gehörige Portion FUD rundet natürlich sogar derart abstoßende
> > Müllpostings wie deines hier negativ nach unten ab.
> DNS soll distributed caching machen.
Ist das ein Antrag auf Sofort-Plonk?
Hat mit dem Thema nichts zu tun, ist eine generische Blah-Aussage wie
"Datenbanken sollen Daten speichern" und beinhaltet nichts, das nicht
schon alle vorher wußten.
Herzlichen Glückwunsch, Rainer.
Felix
Felix von Leitner
> > 629. [bug] 9.1.0b1 dereferenced a null pointer and crashed
> > when responding to a UDP IXFR request.
> Les ich da ein 'b' in der Version? Beta ist zum testen da.
> Fehler macht jeder.
djbdns hatte nie ein DoS und nie einen Buffer Overflow.
qmail auch nicht.
ucspi-tcp auch nicht.
daemontools auch nicht.
checkpassword auch nicht.
[the list goes on]
> >Nur so als Auszug.
> Genau, wir nehmen jetzt alle Fehler, die bei Tests aufgetreten sind als
> security threat an. Schick.
Nein, wir nehmen alle durch Userdaten auslösbaren Buffer Overflows und
DoS-Möglichkeiten. Da waren noch deutlich mehr Bugs.
> >Ach ja, erstaunlich ist auch die Anzahl der Cleanups, die in einem
> >angeblich "clean rewrite from scratch" nötig waren:
> Man kann auch scratch code wieder cleanen.
Nur, wenn man inkompetent ist.
Und das ist meine ganze Aussage an der Stelle.
Die BIND9-Leute sind die gleichen Versager, die uns die BIND8-Bugs
gebracht haben.
> Die Aussage bezieht sich auf die Wiederverwertung von code aus BINDv8.
Du bist unerträglich.
Das einzige Feature von BIND9 ist, daß es keinen Code wiederverwendet.
> DJB schreibt wohl alle code bloecke sofort sauber und ohne Fehler?
Ja.
> Wenn er das projezieren koennte, haett ich den gern als Kanzler.
Er ist Mathematiker, kein Politiker.
> >BIND verkauft jetzt early access für Bugs und Bug-Fixes gegen Geld an
> >ausgewähltes Publikum. Man beachte, daß da nicht stand, daß jeder
> >subscriben darf, wenn er nur Geld zahlt. Nein, da standen Bedingungen,
> >die potentielle Kunden erfüllen müssen.
> Lies mal die FAQ, die Paul auf bind-announce gepostet hat.
Paul's Schadensbegrenzungsmaßnahmen interessieren mich nicht.
Er schrieb, was er schrieb.
Felix
Felix von Leitner
> > > DJB soll erstmal nen vollwertigen DNS-Server auf die Beine stellen,
> > > und dann kann rumplaerren.
> > Was fehlt die denn in seinem?
> DNS NOTIFY, DNS UPDATE,
Du hast offenbar mal nicht mitgekriegt, daß die Ziel bei djbdns
Funktionieren und Sicherheit sind. Damit kommen diese Krücken-Lösungen
nicht in Frage. Wer NOTIFY haben will, für den gibt es ein Perl-Script,
das das leistet. Aber in den Lieferumfang gehört so offensichtlicher
Kompatibilitäts-Cruft nicht, sonst kann er seine $500 in den Hintern
schieben.
> Slave-Verhalten gemaesst SOA,
Bullshit.
Es gibt keine Slaves im Protokoll.
Daniel labert mal wieder über Sachen, die er nicht versteht.
> IPv6 RRs,
> DNSSEC,
DNSSEC ist müll und hat auch mit Sicherheit nichts zu tun.
Das war eine reine Marketing-Aussage, weil PKIs zu dem Zeitpunkt noch
wie eine gute Idee aussaghen, um Kohle zu verdienen.
> forwarding-Domains.
Völlig überflüssiges Konzept.
> Und als Caching Resolver fehlt ihm ein Forwarding.
Nein.
> Und nein, es komme mir bitte keiner mit rsync-over-ssh und cronjobs.
Genu, lieber nichts erwähnen, das zu hoch für Daniel ist.
Es könnte seine "Argumentation" beschädigen.
Felix
Felix von Leitner
> > Wen interessiert denn der FHS?
> Leute, die über 'abandoned months ago'-Systeme stolpern und sich
> wünschten, jemand anderes hätte auch schon mal davon gehört?
Das Problem ist nicht der Standard, sondern daß as System dokumentiert
wurde. Wenn du den Unterschied nicht kennst, hast du nichts an der
Konsole von richtigen Computern verloren.
> > Wenn du das Gegenteil beweisen kannst, wird er dir 500 Dollar
> > auszahlen.
> "Currently, dnscache supports four levels of gluelessness. Will this
> be enough?"
>
> Why do you ask?
Oh, du hast dich gerade selbst widerlegt.
Rainer, vielleicht solltest du mal an einer Entgiftung teilnehmen?
Felix
Tino Reichardt
>Felix von Leitner <usenet-...@fefe.de> writes:
>> Wen interessiert denn der FHS?
>Leute, die über 'abandoned months ago'-Systeme stolpern und sich
>wünschten, jemand anderes hätte auch schon mal davon gehört?
Unterlagen zu den laufenden Diensten/Einstellungen/etc..
Das das nicht immer ganz FHS-konform sein muß (bzw. geht) sieht man
bei allen Distribs !
Minamalsystem rauf, eigene Packages rauf, Einstellungen gut
Dokumentieren und fertich...
TR
W1...@lina.inka.de
> DoS-Möglichkeiten. Da waren noch deutlich mehr Bugs.
>> >Ach ja, erstaunlich ist auch die Anzahl der Cleanups, die in einem
>> >angeblich "clean rewrite from scratch" nötig waren:
>> Man kann auch scratch code wieder cleanen.
> Nur, wenn man inkompetent ist.
> Und das ist meine ganze Aussage an der Stelle.
> Die BIND9-Leute sind die gleichen Versager, die uns die BIND8-Bugs
> gebracht haben.
Da muss ich voll zustimmen. Und wenn mich was an DJB begeistert ist es, dass
qmail 1.0 seine erste Version war die er veroeffentlichte und die keinerlei
scratch code, legacy code oder code der cleanups benoetigte enthielt. Und mal
abgeshen von kleinen Erweiterungen in 1.01 auch Feature-Complete war.
Bei den djbdns tools kann man sich streiten ob die vollstaendig sind, aber bei
einem so kranken Standard wie DNS kann man glaube die nicht-Vollstaendigkeit
als Feature ansehen. Und die Architektur die DJB Benutzt ist ja wohl
unstrittig sicherheitsbewusster als bind je war.
> Paul's Schadensbegrenzungsmaßnahmen interessieren mich nicht.
> Er schrieb, was er schrieb.
Ich weiss nicht, hat wer eine Statistik wieviele Bugs von Paul's Consortien
angekuendigt wurden und wieviele über offene Foren kamen? Ich nehme mal an,
wenn Paul sein Vorhaben durchsetzt eine Closed Group zu schaffen, dann werden
die meisten Bug Report auch nicht mehr den direkten Weg zu Paul waehlen,
sondern direkt Bugtraq, und dann kann er seine no-disclosure policy sich in
die Haare schmieren.
Gruss
Bernd
Rainer Weikusat
> > DNS soll distributed caching machen.
>
> Ist das ein Antrag auf Sofort-Plonk?
Ein Hinweis auf einen Halbsatz aus RFC1035: "[...] depending on who
has cached what [...]".
> ist eine generische Blah-Aussage wie "Datenbanken sollen Daten
> speichern"
Es beschreibt sowohl Unterschiede zwischen dnscache und bind als auch
zwischen DNS und WINS. 'dnscache' kann ich (lt paper) hier nicht so
einhängen, wie ich bind eingehängt haben möchte, also ist er für mich
unbrauchbar.
--
SIGSTOP
Rainer Weikusat
> > DNS soll distributed caching machen.
>
> Ist das ein Antrag auf Sofort-Plonk?
Ein Hinweis auf einen Halbsatz aus RFC1035: "[...] depending on who
has cached what [...]".
> ist eine generische Blah-Aussage wie "Datenbanken sollen Daten
> speichern"
Es beschreibt Unterschiede zwischen dnscache und bind.
'dnscache' kann ich (lt paper) hier nicht so einhängen, wie ich bind
eingehängt haben möchte.
--
SIGSTOP
Philipp Buehler
<usenet-...@fefe.de> wrote:
>djbdns hatte nie ein DoS und nie einen Buffer Overflow.
>> Man kann auch scratch code wieder cleanen.
>
>Nur, wenn man inkompetent ist.
Oder man sich eingestehen kann, dass man etwas besser schreiben kann.
Das muss ja nichtmal ein bug gewesen sein.
>> Die Aussage bezieht sich auf die Wiederverwertung von code aus BINDv8.
>
>Du bist unerträglich.
Es steht Dir absolut frei mich in ein killfile zu stopfen.
>Das einzige Feature von BIND9 ist, daß es keinen Code wiederverwendet.
..von v8.. hab ich doch gesagt.
>> DJB schreibt wohl alle code bloecke sofort sauber und ohne Fehler?
>
>Ja.
Sniffst Du seinen $EDITOR?
>> Wenn er das projezieren koennte, haett ich den gern als Kanzler.
>
>Er ist Mathematiker, kein Politiker.
Er politisiert auf seinen Webseiten aber schon sehr gut.
>Er schrieb, was er schrieb.
Past never changes - exakt. Aber man kann Missverstaendnisse
aufklaeren.
Philipp Buehler
<usenet-...@fefe.de> wrote:
>> IPv6 RRs,
>
>http://www.fefe.de/dns/
Fortunately, Dan Bernstein (the author of djbdns) has defined a
very clean API that made the conversion possible in a few days.
Hm .. ohne jegliche Dokumentation. Wie dokumentiert gibt es keine
A6 oder DNAME-RR. Hm .. und das ist nicht DJB-abgesegnet. Sprich,
keine $500 :} Den Spass hatten wir doch bei qmail schon.
>> DNSSEC,
>DNSSEC ist müll und hat auch mit Sicherheit nichts zu tun.
Beleg das bitte mal an Quellen aus RFC2535/3008 und 2845.
>Das war eine reine Marketing-Aussage, weil PKIs zu dem Zeitpunkt noch
>wie eine gute Idee aussaghen, um Kohle zu verdienen.
Achja, 2535 wurde von IBM geschrieben, und kommerziell ist ja boese.
>> Und nein, es komme mir bitte keiner mit rsync-over-ssh und cronjobs.
>
>Genu, lieber nichts erwähnen, das zu hoch für Daniel ist.
>Es könnte seine "Argumentation" beschädigen.
Es beschaedigt Deine, wenn Du mal einen named auf mehr als UNIX-like
Systemen brauchst. Hidden-Primary auf <IYFMH>-OS, das kein rsync/ssh
unterstuetzt, kann oder schlicht nicht darf.
Felix von Leitner
> > Paul's Schadensbegrenzungsmaßnahmen interessieren mich nicht.
> > Er schrieb, was er schrieb.
> Ich weiss nicht, hat wer eine Statistik wieviele Bugs von Paul's Consortien
> angekuendigt wurden und wieviele über offene Foren kamen? Ich nehme mal an,
> wenn Paul sein Vorhaben durchsetzt eine Closed Group zu schaffen, dann werden
> die meisten Bug Report auch nicht mehr den direkten Weg zu Paul waehlen,
> sondern direkt Bugtraq, und dann kann er seine no-disclosure policy sich in
> die Haare schmieren.
Na wenn er schon Kohle von den Subscribern nimmt, dann kann er damit
auch die Leute bezahlen, damit sie die Bugs ihm und nicht bugtraq sagen.
Felix
Felix von Leitner
> >djbdns hatte nie ein DoS und nie einen Buffer Overflow.
> says who?
Ich.
Der Source Code.
Das Changelog.
Also jeder, der lesen kann.
Wozu du ja wohl offensichtlich nicht zählst :-(
> >> Man kann auch scratch code wieder cleanen.
> >Nur, wenn man inkompetent ist.
> Oder man sich eingestehen kann, dass man etwas besser schreiben kann.
> Das muss ja nichtmal ein bug gewesen sein.
Der Punkt ist: Dans Code braucht keine Cleanups.
Brauchte noch nie und wird wohl auch nie welche brauchen.
> >> Die Aussage bezieht sich auf die Wiederverwertung von code aus BINDv8.
> >Du bist unerträglich.
> Es steht Dir absolut frei mich in ein killfile zu stopfen.
In der Tat.
*plonk*
> >Das einzige Feature von BIND9 ist, daß es keinen Code wiederverwendet.
> ..von v8.. hab ich doch gesagt.
Nein.
> >> DJB schreibt wohl alle code bloecke sofort sauber und ohne Fehler?
> >Ja.
> Sniffst Du seinen $EDITOR?
Djb released alle Nase lang Software und dokumentiert alle Änderungen
seit der ersten unreleaseten Gamma-Version.
> >> Wenn er das projezieren koennte, haett ich den gern als Kanzler.
> >Er ist Mathematiker, kein Politiker.
> Er politisiert auf seinen Webseiten aber schon sehr gut.
Hast du auch was zu sagen oder siehst du nur gerne deinen Namen im
Usenet?
Felix
Felix von Leitner
> >> IPv6 RRs,
> >http://www.fefe.de/dns/
> Fortunately, Dan Bernstein (the author of djbdns) has defined a
> very clean API that made the conversion possible in a few days.
> Hm .. ohne jegliche Dokumentation. Wie dokumentiert gibt es keine
> A6 oder DNAME-RR.
Bin ich der einzige, der hier einen Widerspruch sieht?
> Hm .. und das ist nicht DJB-abgesegnet. Sprich,
> keine $500 :} Den Spass hatten wir doch bei qmail schon.
Hast du eine Sicherheitslücke gefunden?
Dann raus damit. Ansonsten halt die Klappe.
> >> DNSSEC,
> >DNSSEC ist müll und hat auch mit Sicherheit nichts zu tun.
> Beleg das bitte mal an Quellen aus RFC2535/3008 und 2845.
Weniger Privatsphäre: man NXT.
Weniger Sicherheit wegen mehr Code, mehr Komplexität, und in der Tat
waren mehrere Bugs in BIND im DNSSEC-Code.
Ein Stück Scheiße mit Kryptographie ist immer noch ein Stück Scheiße.
> >Das war eine reine Marketing-Aussage, weil PKIs zu dem Zeitpunkt noch
> >wie eine gute Idee aussaghen, um Kohle zu verdienen.
> Achja, 2535 wurde von IBM geschrieben, und kommerziell ist ja boese.
Außer FUD hast du wohl nichts in der Hand, wie?
Daß dir das nicht peinlich ist...!
> >> Und nein, es komme mir bitte keiner mit rsync-over-ssh und cronjobs.
> >Genu, lieber nichts erwähnen, das zu hoch für Daniel ist.
> >Es könnte seine "Argumentation" beschädigen.
> Es beschaedigt Deine, wenn Du mal einen named auf mehr als UNIX-like
> Systemen brauchst. Hidden-Primary auf <IYFMH>-OS, das kein rsync/ssh
> unterstuetzt, kann oder schlicht nicht darf.
Wenn du Windows meinst: man cygwin.
Hidden Primary geht selbstverständlich mit djbdns auch ohne rsync.
Es ist nur nicht sicherer als bei BIND und damit für ernsthaften Einsatz
untauglich.
Felix
Felix von Leitner
> > ist eine generische Blah-Aussage wie "Datenbanken sollen Daten
> > speichern"
> Es beschreibt sowohl Unterschiede zwischen dnscache und bind als auch
> zwischen DNS und WINS. 'dnscache' kann ich (lt paper) hier nicht so
> einhängen, wie ich bind eingehängt haben möchte, also ist er für mich
> unbrauchbar.
dnscache vertraut nur autoritativen Daten.
Das ist ein Feature. man cache poisoning.
Man kann dnscache auch als Forwarder betreiben, wenn man die
Implikationen verstanden hat. Aber dazu muß man, was dich offenbar
überfordert hat, die FAQ lesen:
http://cr.yp.to/djbdns/faq/cache.html#forwardonly
Felix
Rainer Weikusat
> > zwischen DNS und WINS.
Das ist natürlich völliger Müll.
> > 'dnscache' kann ich (lt paper) hier nicht so
> > einhängen, wie ich bind eingehängt haben möchte, also ist er für mich
> > unbrauchbar.
>
> dnscache vertraut nur autoritativen Daten.
> Das ist ein Feature. man cache poisoning.
Falls ich effektiv an hinter einem (mutmaßlich) Uralt-Bind hänge (was
ich tue), gegen den ich nichts unternehmen kann (ich kann den
fraglichen Rechner nicht mal daran hindern, sich über ssh ohne Paßwort
einzuloggen), ist das eine meiner geringeren Sorgen.
> Man kann dnscache auch als Forwarder betreiben, wenn man die
> Implikationen verstanden hat. Aber dazu muß man, was dich offenbar
> überfordert hat, die FAQ lesen:
Wenn mir jemand at length erklärt, warum er X nicht tut, erspare ich
mir im allgemeinen die Mühe, herauszufinden, ob er das nicht vielleicht
doch tut. Zumal daß für unser 'leicht krankes' internes DNS-Setup
immer noch nicht genügen würde.
--
SIGSTOP
Philipp Buehler
<usenet-...@fefe.de> wrote:
>> Hm .. ohne jegliche Dokumentation. Wie dokumentiert gibt es keine
>> A6 oder DNAME-RR.
>
>Bin ich der einzige, der hier einen Widerspruch sieht?
Source und einmal die Webseite gemeint habe.
-v -v: Im source ist praktisch keine Doku, und auf der Webseite
steht, dass der derzeit nur AAAA unterstuetzt wird. Und nur *das*
steht dort (auch wenn der Source mehr zu tun scheint, ich
quael mich da jetzt nicht durch)
>> Hm .. und das ist nicht DJB-abgesegnet. Sprich,
>> keine $500 :} Den Spass hatten wir doch bei qmail schon.
>Hast du eine Sicherheitslücke gefunden?
>Dann raus damit. Ansonsten halt die Klappe.
Ich verbessere mich auf: keine potentiellen $500.
Und die nicht-Absegnung ist bisher Tatsache.
>> >> DNSSEC,
>> >DNSSEC ist müll und hat auch mit Sicherheit nichts zu tun.
>> Beleg das bitte mal an Quellen aus RFC2535/3008 und 2845.
>
>Weniger Privatsphäre: man NXT.
Seit *wann* hat DNS etwas mit Privatsphaere zu tun? Wenn Du gewisse
resolvings nicht haben willst, dann setz ACLs auf fuer delegierte
private-usage Zonen.
Oh natuerlich $attacker kann sich natuerlich Namen ausdenken und
die anfragen und einen Treffer landen, sprich kein NXT bekommen und
dann auf die Maschine Attacken fahren. Oh, da versteckt einer DNS
Daten? Schicke Obscurity.
>Weniger Sicherheit wegen mehr Code, mehr Komplexität, und in der Tat
>waren mehrere Bugs in BIND im DNSSEC-Code.
>
>Ein Stück Scheiße mit Kryptographie ist immer noch ein Stück Scheiße.
Deine Ausdrucksweise ist auch <das Wort mit Sch, das im letzten Satz zwei mal
vorkommt>.
Aber gehen wir doch mal ins CHANGELOG, dass Du ja schonmal zitiert hast,
und es jetzt mal schoen bleiben hast. Hm..
reichlich leer fuer security relevante bugs. Erst zweimal fuer alles,
das nicht beta-signed ist.
>> >Das war eine reine Marketing-Aussage, weil PKIs zu dem Zeitpunkt noch
>> >wie eine gute Idee aussaghen, um Kohle zu verdienen.
>> Achja, 2535 wurde von IBM geschrieben, und kommerziell ist ja boese.
>
>Außer FUD hast du wohl nichts in der Hand, wie?
2535 *ist* von IBM, wo ist da der FUD. Dass Du kommerziell nicht magst,
ist deutlich in Deinen Postings zu lesen.
>Daß dir das nicht peinlich ist...!
Peinlich ist, wenn Leute technische Diskussionen auf
persoenliche Flames herabziehen. Throw facts not flames.
>> Es beschaedigt Deine, wenn Du mal einen named auf mehr als UNIX-like
>> Systemen brauchst. Hidden-Primary auf <IYFMH>-OS, das kein rsync/ssh
>> unterstuetzt, kann oder schlicht nicht darf.
>
>Wenn du Windows meinst: man cygwin.
Und man lese den Halbsatz ``kann oder schlicht nicht darf.'' nochmal.
>Hidden Primary geht selbstverständlich mit djbdns auch ohne rsync.
>Es ist nur nicht sicherer als bei BIND und damit für ernsthaften Einsatz
>untauglich.
Logic is a nice toy. Das heisst, dass djbdns fuer Systeme die kein ssh/rsync
unterstuetzen nicht fuer ernsthaften Einsatz tauglich ist. Danke.
(unterstuetzen im Sinne von: koennen, wollen, duerfen)
Philipp Buehler
<usenet-...@fefe.de> wrote:
>Philipp Buehler <p...@usenet-feb-2001.fips.de> wrote:
>> >djbdns hatte nie ein DoS und nie einen Buffer Overflow.
>> says who?
>Ich.
>Der Source Code.
>Das Changelog.
>Also jeder, der lesen kann.
Ich kann lesen, aber C-code nicht auditen, erst zweimal
nicht solchen, wie von Dir, der nichtmal interne Doku hat.
>Wozu du ja wohl offensichtlich nicht zählst :-(
Nein, sicher nicht. Aber es wuerde mich brennend interessieren,
wieviel Profis sich dem Code schon angenommen haben *und* das
offiziell dokumentiert worden ist.
In-offiziell hab ich da schon andere Sachen gehoert, aber
das ist nicht proven und damit irrelevant. Warm fuzzy feeling
gibt *mir* das aber nicht.
>Der Punkt ist: Dans Code braucht keine Cleanups.
>Brauchte noch nie und wird wohl auch nie welche brauchen.
(Fuer spaetere Wiederverwendung gespeichert)
>> >> Die Aussage bezieht sich auf die Wiederverwertung von code aus BINDv8.
>> >Du bist unerträglich.
>> Es steht Dir absolut frei mich in ein killfile zu stopfen.
>In der Tat.
>*plonk*
Mist, alles umsonst. Aber der restlichen Gemeinde zur Lektuere schreib
ich mal weiter.
>> >Das einzige Feature von BIND9 ist, daß es keinen Code wiederverwendet.
>> ..von v8.. hab ich doch gesagt.
>Nein.
Message-ID: <95jt4m$10f$3...@serpens.de>:
``Die Aussage bezieht sich auf die Wiederverwertung von code aus BINDv8.''
Wie jetzt 'Nein.' ?
>> >> DJB schreibt wohl alle code bloecke sofort sauber und ohne Fehler?
>> >Ja.
>> Sniffst Du seinen $EDITOR?
>
>Djb released alle Nase lang Software und dokumentiert alle Änderungen
>seit der ersten unreleaseten Gamma-Version.
Der Punkt ist, dass DJB seinen Code in der stillen Kammer schreibt.
Woher willst Du wissen, was er verbockt hatte und vor einem Release
veroeffentlich dokumentiert. Achja, man kann natuerlich auch DJB
einfach vertrauen, dass er tut, was man meint; oder so aehnlich.
>> >> Wenn er das projezieren koennte, haett ich den gern als Kanzler.
>> >Er ist Mathematiker, kein Politiker.
>> Er politisiert auf seinen Webseiten aber schon sehr gut.
>
>Hast du auch was zu sagen oder siehst du nur gerne deinen Namen im
>Usenet?
Oh, es geht ja schon wieder ins persoenliche. Hm, also der einzige,
der hier vorrangig ohne Fakten irgendwas schreibt und damit seinen
Namen im Usenet sieht hat mich "leider" ge*plonk*t.
Alexander Bochmann
Felix von Leitner wrote:
> Daniel Roesen <dro...@entire-systems.com> wrote:
> > > > ISC ist non-profit.
> > > Ein Glück, daß Herr Roesen mal wieder in vollem Umfang informiert ist,
> > > bevor er Müll postet...
> Wenn du mal genau hinschaust, wirst du feststellen, daß BIND9 nicht von
> ISC programmiert wurde. ISC dient nur als Mäntelchen, damit ihnen
> auf den ersten Blick keine Kommerz-Schweinereien vorzuwerfen sind.
> Tatsächlich hat eine weitere Vixie-Company BIND9 implementiert: Nominum.
Na und? Viele freie Software ist von for-profit Companies entwickelt
oder weiterentwickelt worden. Wen stoert das? Wenn sie meinen, sie
muessten zu irgendeinem Zeitpunkt spezifische Weiterentwicklungen
closed-Source machen (man sendmail), dann stoert das verdammt wenig -
die bisherigen Versionen gibt es weiterhin und sie koennen
weiterentwickelt werden (um beim Beispiel zu bleiben - schonmal was von
ida-sendmail gehoert?).
> > > They give us configuration problems and then sell support services;
> > Habe noch keine Konfigurationsprobleme gehabt, bei denen ich Support
> > einkaufen haette muessen.
> Wir verbeugen uns vor deiner Großartigkeit, Daniel.
Ich glaube nicht, dass er dabei alleine ist.
> Selbst mir, auf meiner Stink-Normal-1CPU-Linux 2.2 Box mit
> Only-Stable-Versions Userland mit vier Pissels-Domains und einer
> Handvoll DNS-Anfragen pro Tag, ist BIND 8.2.2 plus Security Patches of
> the day alle 14+rand()%7 Tage abgeraucht. Regelmäßig. Ohne warnende
Kauf Dir mal neue Hardware. Oder ein vernuenftiges OS. Die Uptime
unseres bind (knapp 500 primary-Zonen und knapp 1000 secondary-Zonen und
resolver fuer einen Haufen Leute) ist im Normalfall gleich der Uptime
der Maschine, wo er drauf laeuft - im Moment 207 Tage. Nagut, ich glaube
ich muss mich korrigieren, einmal ist er in der Zeit abgeschmiert, weil
die Kiste aus anderen Gruenden out of swap space war.
> Du hast gerade das das Niveau von Kooks wie Frank Werner und Lars
> Kaehler deutlich nach unten durchschlagen. Die tun wenigstens nicht so,
> als wüßten sie, wovon sie sprechen.
*gaehn*
Man sollte vielleicht ein bischen unauffaelliger auf die Seite springen,
wenn einem die Argumente ausgehen.
Alex.
Alexander Bochmann
Felix von Leitner wrote:
> dnscache vertraut nur autoritativen Daten.
> Das ist ein Feature. man cache poisoning.
man trust-level.
Woher weisst Du, dass die "autoritativen Daten" echt sind?
Wer Daten aus dem DNS fuer irgendwas wichtiges vertraut, dem ist eh
nicht zu helfen. Das hat nichts mit BIND zu tun, sondern mit dem
gesamten Internet-Umfeld in seiner heutigen Form. Das
Sicherheitsparadigma von TCP/IP sind trusted hosts, die ihre User lokal
wirkungsvoll authentifizieren - sowas gibt's heutzutage nur noch auf
einsamen Inseln.
Alex.
Alexander Bochmann
> Daniel Roesen <dro...@entire-systems.com> wrote:
> > > > DJB soll erstmal nen vollwertigen DNS-Server auf die Beine stellen,
> > > Was fehlt die denn in seinem?
> > DNS NOTIFY, DNS UPDATE,
> Du hast offenbar mal nicht mitgekriegt, daß die Ziel bei djbdns
> Funktionieren und Sicherheit sind. Damit kommen diese Krücken-Lösungen
> nicht in Frage.
Genau, das Internet ist seit Jahren kaputt[tm], weil 99.5% der
Unix-Nameserver auf BIND basieren. Vom Resolver wollen wir mal garnicht
reden.
> das das leistet. Aber in den Lieferumfang gehört so offensichtlicher
> Kompatibilitäts-Cruft nicht, sonst kann er seine $500 in den Hintern
> schieben.
Wenn jemand gut an BIND verdient, dann wahrscheinlich O'Reilly - und
selbst das halte ich fuer positiv, weil es wenigstens ein bischen Ahnung
von der Materie durch die Gegend streut. Was nuetzt ein tolles,
einfaches System, wenn keiner weiss, wie die Grundlagen aussehen, auf
denen es basiert? Das Ergebnis sieht man bei Windows - die Cluesenke
schlechthin.
Man kann immer ganz einfach ganz toll aussehen, wenn man sich darauf
beschraenkt, nur in seinem eigenen Sandkasten zu spielen und alle
anderen fuer doof zu erklaeren - wenn man mit ihnen auf einer Ebene
aufgrund allgemeiner Uebereinkuenfte zusammenarbeiten muss, sieht das
ganz anders aus.
> > Slave-Verhalten gemaesst SOA,
> Bullshit.
> Es gibt keine Slaves im Protokoll.
> Daniel labert mal wieder über Sachen, die er nicht versteht.
Genau, weil es keine Slaves im Protokoll gibt, ist ja auch der AXFR
query type definiert. Den braucht naemlich absolut jeder, der kein Slave
ist.
Falls Du noch nichts davon gehoert hast bisher, die offizielle
Definition fuer dich:
RFC2182:
Secondary Server An authoritative server that obtains
information about a zone from a Primary Server
via a zone transfer mechanism. Sometimes
known as a Slave Server.
> > Und nein, es komme mir bitte keiner mit rsync-over-ssh und cronjobs.
> Genu, lieber nichts erwähnen, das zu hoch für Daniel ist.
> Es könnte seine "Argumentation" beschädigen.
Siehe oben. rsync-over-whatever ist ein reines
nur-fuer-meinen-Sandkasten Spiel.
Alex.
Alexander Bochmann
Felix von Leitner wrote:
> Hidden Primary geht selbstverständlich mit djbdns auch ohne rsync.
> Es ist nur nicht sicherer als bei BIND und damit für ernsthaften Einsatz
> untauglich.
Hach, erst die zweite News heute und schon wiederhole ich mich - Du hast
Dich in den letzten 6 oder 8 Jahren oder so mal im Internet umgeschaut
oder? Dort gibt es keine Leute, die irgendwas ernsthaft machen Deiner
Meinung nach, nehme ich mal an?
Genau.
Alex.
W1...@lina.inka.de
> Aber gehen wir doch mal ins CHANGELOG, dass Du ja schonmal zitiert hast,
> und es jetzt mal schoen bleiben hast. Hm..
> reichlich leer fuer security relevante bugs. Erst zweimal fuer alles,
> das nicht beta-signed ist.
Gruss
Bernd
W1...@lina.inka.de
> Genau, das Internet ist seit Jahren kaputt[tm], weil 99.5% der
> Unix-Nameserver auf BIND basieren. Vom Resolver wollen wir mal garnicht
> reden.
Sagen wir es mal so, wenn man sich die trivialen Exploits in dem Bereich
anschaut kann man durchaus zu dem Schluss kommen.
Sich auf DNS bei irgendwas security kritischem zu verlassen ist purer
Leichtsinn.
Gruss
Bernd
Philipp Buehler
<W1...@lina.inka.de> wrote:
>> reichlich leer fuer security relevante bugs. Erst zweimal fuer alles,
>> das nicht beta-signed ist.
>BITTE? Das sind dann ja wohl 2 zu viel.
Aber hallo.
Alexander Bochmann
W1...@lina.inka.de wrote:
> Sich auf DNS bei irgendwas security kritischem zu verlassen ist purer
> Leichtsinn.
Wie ich schon vorhin in nem anderen Artikel geschrieben habe, kann BIND
da nur bedingt was dafuer. Abgesehen davon, dass BIND wie jede Software
(ausser der von ganz bestimmten Personen, die hier schon oefters
erwaehnt wurden) Bugs hat, ist es eine Implementation bestehender
Spezifikationen, die selbst nicht fehlerfrei sind.
Allerdings ist DNS grundsaetzlich ein System, bei dem andere Leute die
Autoritaet ueber Daten haben, die man lokal verwendet. Auf so etwas
_will_ man sich so oder so nicht verlassen bei irgendwas security
kritischem.
Alex.
Alexander Bochmann
Felix von Leitner wrote:
> Philipp Buehler <p...@usenet-feb-2001.fips.de> wrote:
> > >djbdns hatte nie ein DoS und nie einen Buffer Overflow.
> > says who?
> Ich.
Der war gut.
> Hast du auch was zu sagen oder siehst du nur gerne deinen Namen im
> Usenet?
...und das ist der kroenende Abschluss des Tages.
Alex.
Philipp Hemker
> Der Punkt ist: Dans Code braucht keine Cleanups.
Welche Art "Code" würde denn "Cleanups" brauchen?
Was sind überhaupt "Cleanups"?
unsigned int str_len(const char *s)
{
register const char *t;
t = s;
for (;;) {
if (!*t) return t - s; ++t;
if (!*t) return t - s; ++t;
if (!*t) return t - s; ++t;
if (!*t) return t - s; ++t;
}
}
bis dann,
philipp
--
W1...@lina.inka.de
> for (;;) {
> if (!*t) return t - s; ++t;
> if (!*t) return t - s; ++t;
> if (!*t) return t - s; ++t;
> if (!*t) return t - s; ++t;
> }
Jetzt balmierst du dich entgültig...
So was nennt man Loop Unrolling.
Gruss
Bernd
Marc Haber
>> > Wen interessiert denn der FHS?
>> Leute, die über 'abandoned months ago'-Systeme stolpern und sich
>> wünschten, jemand anderes hätte auch schon mal davon gehört?
>
>Das Problem ist nicht der Standard, sondern daß as System dokumentiert
>wurde.
Wieviele "abandoned months ago"-Systeme mit sauberer, aktueller
Dokumentation hast Du im Leben schon gesehen?
Standard sind gut. Man sollte sich daran halten. Und wenn man das
schon nicht selbst fertigbringt, sollte man den Usern seiner Software
nicht verbieten [1], sich an Standards zu halten.
Grüße
Marc
[1] ersetze verbieten gegebenenfalls durch "schwer machen".
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
Marc Haber
>* Marc Haber <usene...@marc-haber.de> writes:
>> bpa...@gmx.net (H. Gremming) wrote:
>
>>> You are permitted to distribute a precompiled djbdns package if
>>> (kannst du aber selbst lesen: http://cr.yp.to/djbdns/dist.html)
>
>> ja, Du darfst aber die Pfade nicht ändern.
>
>/Er/ darf die Pfade selbstverständlich ändern. Es dürfen nur keine
>kompilierten Binaries mit anderen Pfaden verteilt werden. Es spricht
>aber nichts gegen SRPMs oder ports.
Klasse. Entwicklungsumgebungen auf Servern?
>> Und da djb's Auswahl der Installationspfade diplomatisch ausgedrückt
>> etwas eigenwillig (und keinesfalls FHS compliant) ist,
>
>Sie sind aber ausgezeichnet begründet.
Trotzdem ist es mein gutes Recht, anderer Meinung zu sein. Und es ist
ebenfalls mein gutes Recht, djb's Software links liegen zu lassen,
wenn mir seine Lizenz erschwert, meine andere Meinung auf meinen
System durchzusetzen. Im Bereich mail gibt es gute Alternativen, im
Bereich DNS leider (noch?) nicht.
Grüße
Marc
Marc Haber
>So was nennt man Loop Unrolling.
IMO sollte man sowas in portabler Software dem Compiler überlassen.
Gerd Knorr
> > ausliefern darf, was beispielsweise im Widerspruch zu den Debian
> > Spielregeln steht.
>
> Ja und?
> Was interessiert das dich als DNS-Serverbetreiber?
Ich kann kein "apt-get install djbdns" machen.
> Du kannst dir gerne selber Binärpakete von modifizierten Versionen
> basteln und intern verteilen.
Klar kann ich (was bei djb's Software übrigens ein paar Klimmzüge
erfordert). Aber ich wäre nicht direkt böse darüber wenn mir die
Distribution das abnehmen würde.
Gerd
--
document.write('<noscript> ... </noscript>');
-- gefunden in einem pixelpark flash banner
Lutz Donnerhacke
>Wenn du das Gegenteil beweisen kannst, wird er dir 500 Dollar auszahlen.
>Ansonsten halte doch einfach die Klappe, OK? Danke.
Contests im Bereich von Security Produkten sind BAD(tm).ą
djb Software hat ein wesentliches Manko: Es konvertiert Nutzer zu Fanatikern.
djbdns ist in etwas anders gelagert. Er versucht nicht, einen unfairen
Contest anzubieten und dann zu bahaupten, es wäre deswegen sicher.
Felix von Leitner
> >So was nennt man Loop Unrolling.
> IMO sollte man sowas in portabler Software dem Compiler überlassen.
Marc, würde es dir etwas ausmachen, dich ab jetzt nur noch zu Themen zu
äußern, mit denen du dich auskennst?
Danke.
Felix
PS: ARGH!
Felix von Leitner
> Wieviele "abandoned months ago"-Systeme mit sauberer, aktueller
> Dokumentation hast Du im Leben schon gesehen?
Mehr als ich Systeme gesehen habe, die sich an Standards halten.
Felix
Felix von Leitner
> Genau, das Internet ist seit Jahren kaputt[tm], weil 99.5% der
> Unix-Nameserver auf BIND basieren. Vom Resolver wollen wir mal garnicht
> reden.
Entschuldige mal bitte, TAUSENDE von Hosts sind über triviale
BIND-Exploits ger00tet und als Trin00-Clients verwendet worden, es gab
sogar einen _Wurm_, der sich über BIND verbreitet hat. Was brauchst du
noch, damit du mal merkst, daß BIND ein Sicherheitsproblem ist?
> Man kann immer ganz einfach ganz toll aussehen, wenn man sich darauf
> beschraenkt, nur in seinem eigenen Sandkasten zu spielen und alle
> anderen fuer doof zu erklaeren - wenn man mit ihnen auf einer Ebene
> aufgrund allgemeiner Uebereinkuenfte zusammenarbeiten muss, sieht das
> ganz anders aus.
Wie alt bist du denn, daß du hier ständig mit Sandkästen zu
argumentieren versuchst? ;-)
Deine Argumentation ist komplett an den Haaren herbeigezogen.
Wenn die Leute das schon alle nicht drauf haben, dann heißt das ja
nicht, daß man selber das nicht trotzdem richtig machen kann, indem man
das Vertrauen in externe Daten minimiert.
man Grundlagen(Security)
> > > Slave-Verhalten gemaesst SOA,
> > Bullshit.
> > Es gibt keine Slaves im Protokoll.
> > Daniel labert mal wieder über Sachen, die er nicht versteht.
> Genau, weil es keine Slaves im Protokoll gibt, ist ja auch der AXFR
> query type definiert. Den braucht naemlich absolut jeder, der kein Slave
> ist.
In der Tat brauche ich AXFR ab und zu.
Aber auch ansonsten ist deine Argumentation für den Fuß, denn DNS
definiert auch einen Haufen anderer überflüssiger Sachen.
Siehe http://www.fefe.de/dns/dns.pdf
> > > Und nein, es komme mir bitte keiner mit rsync-over-ssh und cronjobs.
> > Genu, lieber nichts erwähnen, das zu hoch für Daniel ist.
> > Es könnte seine "Argumentation" beschädigen.
> Siehe oben. rsync-over-whatever ist ein reines
> nur-fuer-meinen-Sandkasten Spiel.
Ich habe lange nicht mehr so einen Quark gelesen.
Felix
Felix von Leitner
> > Ja und?
> > Was interessiert das dich als DNS-Serverbetreiber?
> Ich kann kein "apt-get install djbdns" machen.
Natürlich könntest du das, sogar mit FHS-kompatiblen Pfaden, wenn Debian
das on-the-fly kompilieren würde.
Aber bei Debian heult und winselt man lieber als zu handeln.
> > Du kannst dir gerne selber Binärpakete von modifizierten Versionen
> > basteln und intern verteilen.
> Klar kann ich (was bei djb's Software übrigens ein paar Klimmzüge
> erfordert).
Klimmzüge?
Wovon sprichst du?
echo /opt/djbdns > conf-cc && make && sudo make setup && cd / && \
tar czf tmp/djbdns-bin.tar.gz opt/djbdns etc/dnsroots.global
Sieht das irgendwie komplex oder schwierig aus?
> Aber ich wäre nicht direkt böse darüber wenn mir die
> Distribution das abnehmen würde.
Wende dich an deine Distribution, nicht an djb.
Im Übrigen finde ich "make setup" nicht zuviel verlangt.
Felix
Felix von Leitner
> >> Und da djb's Auswahl der Installationspfade diplomatisch ausgedrückt
> >> etwas eigenwillig (und keinesfalls FHS compliant) ist,
> >Sie sind aber ausgezeichnet begründet.
> Trotzdem ist es mein gutes Recht, anderer Meinung zu sein. Und es ist
> ebenfalls mein gutes Recht, djb's Software links liegen zu lassen,
> wenn mir seine Lizenz erschwert, meine andere Meinung auf meinen
> System durchzusetzen. Im Bereich mail gibt es gute Alternativen, im
> Bereich DNS leider (noch?) nicht.
Wieso kannst du eigentlich nicht aufhören, die Lüge zu verbreiten, daß
djb's Lizenz dir erschwert, auf deinem System die Pfade zu ändern?
Ist das so schwer zu verstehen?
Willst du den Troll-of-the-Week Award einsacken?
Felix
Gerd Knorr
> Wovon sprichst du?
Den ganzen Kram unter <some-tmpdir>/usr installieren, und dann
den Inhalt von <some-tmpdir> in ein Paket (deb, rpm oder was
auch immer) zu wickeln. Und zwar so daß man hinterher passende
Pfade in den Binaries hat. Achja: das ganze sollte möglichst
auch für normale user funkionieren.
> echo /opt/djbdns > conf-cc && make && sudo make setup && cd / && \
> tar czf tmp/djbdns-bin.tar.gz opt/djbdns etc/dnsroots.global
Ich möchte auch selbstgebaute Pakete im Paketmanagement der
Distribution drinhaben. Ein tarball leistet das nicht.
> Sieht das irgendwie komplex oder schwierig aus?
Es macht nicht das was ich will. Das sieht eher so aus:
%build
echo <some-tmpdir>/usr > conf-cc
make install
cp install buildroot-install
echo /usr > conf-cc
make
%install
cp buildroot-install install
make setup
Bei fast allen anderen Softwarepaketen kann man einfach
ein "make DESTDIR=<some-tmpdir> install" oder
"make prefix=<some-tmpdir>/usr install" machen um nach dem
durchbauen den Kram nach <some-tmpdir> statt in's laufende
System zu installieren.
> > Aber ich wäre nicht direkt böse darüber wenn mir die
> > Distribution das abnehmen würde.
>
> Wende dich an deine Distribution, nicht an djb.
*Mööp*. Geht eben nicht wegen der Lizenz. Goto ein paar
Postings zurück im Thread ...
Dietz Proepper
>On Sun, 04 Feb 2001 20:33:51 GMT, Felix von Leitner
><usenet-...@fefe.de> wrote:
>>> Hm .. ohne jegliche Dokumentation. Wie dokumentiert gibt es keine
>>> A6 oder DNAME-RR.
>>
>>Bin ich der einzige, der hier einen Widerspruch sieht?
>Ach herrje, ich habe nicht geschrieben, dass ich einmal den
>Source und einmal die Webseite gemeint habe.
>-v -v: Im source ist praktisch keine Doku, und auf der Webseite
Felix ist üblicherweise der Meinung, er sei ein so guter coder
daß jedem der nicht unfähig ist das Ziel seines Codes durch
Querlesen offenbar wird. Ist imnsho eine der eleganteren Ausreden
für Faulheit.
Dietz
Dietz Proepper
[djbdns]
>> Und als Caching Resolver fehlt ihm ein Forwarding.
>
>Nein.
Du willst Deine Behauptung belegen. Dies willst Du nicht mit
dem Verweis auf die shitheadiness Deiner Diskussionspartner
sondern durch Verweis auf die Doku oder gar konkrete Beispiele
tun.
nb: für 1.04 weiß ich's nicht, für 1.0 bin ich mir äußerst sicher
daß es nicht geht.
Dietz
Dietz Proepper
>Sich auf DNS bei irgendwas security kritischem zu verlassen ist purer
>Leichtsinn.
Wie auch in jedem (brauchbaren) Dokument mit "IP" und "sec" im Titel
seit 1989 zu lesen seien dürfte...
Dietz
Dietz Proepper
Inzwischen weiß ich daß es ab 1.03 geht. Zu dumm wenn man erst
nach dem Posten nachschaut...
Die 'Asche über Haupt streuend' tz
Marc Haber
>> Trotzdem ist es mein gutes Recht, anderer Meinung zu sein. Und es ist
>> ebenfalls mein gutes Recht, djb's Software links liegen zu lassen,
>> wenn mir seine Lizenz erschwert, meine andere Meinung auf meinen
>> System durchzusetzen. Im Bereich mail gibt es gute Alternativen, im
>> Bereich DNS leider (noch?) nicht.
>
>Wieso kannst du eigentlich nicht aufhören, die Lüge zu verbreiten, daß
>djb's Lizenz dir erschwert, auf deinem System die Pfade zu ändern?
"Meine" Systeme sind auch Systeme, die an unsere Kunden verkauft
(sic!) wurden, und die wir nach Installation weitermanagen. Würde ich
DJB-Software einsetzen, müßte ich sie unverändert lassen. Und das will
ich nicht - ich will, dass meine Systeme so nah wie möglich am FHS
sind.
Deswegen kann ich DJB-Software nicht einsetzen.
Alexander Schreiber
>> > Es steht übrigens auch drin daß man keine gepatchten binaries
>> > ausliefern darf, was beispielsweise im Widerspruch zu den Debian
>> > Spielregeln steht.
>>
>> Ja und?
>> Was interessiert das dich als DNS-Serverbetreiber?
>
>Ich kann kein "apt-get install djbdns" machen.
Dann compilier Dir das mit Deinen Einstellungen lokal und bau Dein eigenes
.deb draus. Das ist ja nun wirklich alles andere als schwer.
>> Du kannst dir gerne selber Binärpakete von modifizierten Versionen
>> basteln und intern verteilen.
>
>Klar kann ich (was bei djb's Software übrigens ein paar Klimmzüge
>erfordert). Aber ich wäre nicht direkt böse darüber wenn mir die
>Distribution das abnehmen würde.
Soll sie Dich vielleicht noch an der Hand nehmen?
Wenn sich ''Unix-Admins'' heutzutage nicht mal mehr trauen, Software aus
den Quellen anzupassen und zu installieren - dann gute Nacht.
Man liest sich,
Alex.
--
------------------------------------------------------------------------------
EMail : a...@thangorodrim.de | WWW : http://www.thangorodrim.de/
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison
Alexander Schreiber
>> Klimmzüge?
>> Wovon sprichst du?
>
>Den ganzen Kram unter <some-tmpdir>/usr installieren, und dann
>den Inhalt von <some-tmpdir> in ein Paket (deb, rpm oder was
>auch immer) zu wickeln. Und zwar so daß man hinterher passende
>Pfade in den Binaries hat. Achja: das ganze sollte möglichst
>auch für normale user funkionieren.
man fakeroot
>> echo /opt/djbdns > conf-cc && make && sudo make setup && cd / && \
>> tar czf tmp/djbdns-bin.tar.gz opt/djbdns etc/dnsroots.global
>
>Ich möchte auch selbstgebaute Pakete im Paketmanagement der
>Distribution drinhaben. Ein tarball leistet das nicht.
man alien
>> > Aber ich wäre nicht direkt böse darüber wenn mir die
>> > Distribution das abnehmen würde.
>>
>> Wende dich an deine Distribution, nicht an djb.
>
>*Mööp*. Geht eben nicht wegen der Lizenz. Goto ein paar
>Postings zurück im Thread ...
Natuerlich geht das. Nicht als fertiges Binary, korrekt - aber z.B. nach dem
Prinzip der BSD-Ports: Original-Sourcen nehmen, auspacken, eigenen Patch
drauf, compilieren, lokales Package bauen, Package normal installieren,
fertig. Laeuft vollautomatisch.
Felix von Leitner
> >Wenn du das Gegenteil beweisen kannst, wird er dir 500 Dollar auszahlen.
> >Ansonsten halte doch einfach die Klappe, OK? Danke.
Sie sind nicht automatisch schlecht.
Gewisse "naheliegende" Schlußfolgerungen sind schlecht.
Das Linux Deathmatch z.B. ist als Contest nicht schlecht.
> djb Software hat ein wesentliches Manko: Es konvertiert Nutzer zu Fanatikern.
Ich kann das nicht schlecht finden, wenn die Leute mal aus ihrem Tran
gerissen werden. Manche haben halt eine größere Masseträgheit, und die
wehren sich dann halt lautstark. Manche, mit besonders größer Trägheit
und besonders wenig Argumenten dahinter, wie Herr Rösen z.B., machen
besonders viel Lärm. Wen man dann als Fanatiker brandmarken soll ist
in meinen Augen nicht eindeutig.
> djbdns ist in etwas anders gelagert. Er versucht nicht, einen unfairen
> Contest anzubieten und dann zu bahaupten, es wäre deswegen sicher.
Der Contest von qmail entspricht dem von djbdns ziemlich exakt.
In beiden Fällen wird definiert, welche Art von Angriffen er für
protokollinhärent hält und die daher nicht als Angriff auf djbdns/qmail
qualifizieren.
Felix
Felix von Leitner
> >Wieso kannst du eigentlich nicht aufhören, die Lüge zu verbreiten, daß
> >djb's Lizenz dir erschwert, auf deinem System die Pfade zu ändern?
> "Meine" Systeme sind auch Systeme, die an unsere Kunden verkauft
> (sic!) wurden, und die wir nach Installation weitermanagen.
Da die Software eh kostenlos abrufbar ist, verkaufst du nicht die
Software, sondern den Installationsservice, d.h. du installierst auf dem
Rechner des Kunden.
Die Installation von djbdns läßt sich als eine Zeile in der Shell
ausdrücken. Wenn dir das zuviel Aufwand ist, hast du die Schmerzen von
BIND verdient. Und zwar alle.
> Würde ich DJB-Software einsetzen, müßte ich sie unverändert lassen.
> Und das will ich nicht - ich will, dass meine Systeme so nah wie
> möglich am FHS sind.
>
> Deswegen kann ich DJB-Software nicht einsetzen.
Lügner.
Wobei, man kann das ja auch als Service an die Community werten; freie
Shells für jeden. Und dazu noch ohne Traffickosten! Und ausfallsicher,
da über viele unterschiedlich angebundene Rechner verteilt.
So gesehen ist deine Initiative und Lernresistenz regelrecht lobenswert.
Felix
H. Gremming
> "Robin S. Socha" <ro...@socha.net> wrote:
> >* Marc Haber <usene...@marc-haber.de> writes:
> >> bpa...@gmx.net (H. Gremming) wrote:
> >/Er/ darf die Pfade selbstverständlich ändern. Es dürfen nur keine
> >kompilierten Binaries mit anderen Pfaden verteilt werden. Es spricht
> >aber nichts gegen SRPMs oder ports.
>
> Klasse. Entwicklungsumgebungen auf Servern?
Wozu ?
Wenn du von einem monatlichen update ausgehst:
das ist nicht nötig.
> >> Und da djb's Auswahl der Installationspfade diplomatisch ausgedrückt
> >> etwas eigenwillig (und keinesfalls FHS compliant) ist,
> >
> >Sie sind aber ausgezeichnet begründet.
>
> Trotzdem ist es mein gutes Recht, anderer Meinung zu sein. Und es ist
> ebenfalls mein gutes Recht, djb's Software links liegen zu lassen,
> wenn mir seine Lizenz erschwert, meine andere Meinung auf meinen
> System durchzusetzen.
Du kannst auch bind einsetzen - mit allen Konsequenzen.
Oder deine Meinung ändern.
Heinrich
--
http://felix2.2y.net/
H. Gremming
> * Felix von Leitner wrote:
> >Wenn du das Gegenteil beweisen kannst, wird er dir 500 Dollar auszahlen.
> >Ansonsten halte doch einfach die Klappe, OK? Danke.
>
> Contests im Bereich von Security Produkten sind BAD(tm).
>
> djbdns ist in etwas anders gelagert. Er versucht nicht, einen unfairen
> Contest anzubieten und dann zu bahaupten, es wäre deswegen sicher.
Stichwort "quality game" im Frage- und Antwort-Spiel von P.V.
(Qualität als Spiel anzusehen ist nicht meine Idee):
> Q: Other DNS software publishers promise 0 defects and even offer rewards.
> Why can't ISC seem to compete at the quality game?
> A: If someone else's DNS software ever runs on 80% of the Internet's name
> servers and is shipped in source form that can run on a dozen or more
> architectures, ISC will certainly feel that we have much to learn from
> the authors of that software.
Ich interpretiere das so: wir beherrschen den Markt, was schert uns
der Rest. Im übrigen verwandeln sich mit dem Herrenclub gerade
Bugs in Bucks, warum sollte er darauf verzichten :-)
Heinrich
--
H. Gremming
> > > Es steht übrigens auch drin daß man keine gepatchten binaries
> > > ausliefern darf, was beispielsweise im Widerspruch zu den Debian
> > > Spielregeln steht.
> >
> > Ja und?
> > Was interessiert das dich als DNS-Serverbetreiber?
>
> Ich kann kein "apt-get install djbdns" machen.
Ich kenne apt-get nicht. Wird da kein script ausgeführt ?
Heinrich
p.s.: Es besteht natürlich die Gefahr, das Viexie die
Debian-Maintainer in seinem Club nicht mehr duldet,
wenn sie djb unters Volk bringen.
--
Stefan Nobis
> Wenn sich ''Unix-Admins'' heutzutage nicht mal mehr trauen, Software aus
> den Quellen anzupassen und zu installieren - dann gute Nacht.
Was soll das? Eine Distribution nimmt viel lästige, zeitaufwendige
(Zeit=Geld!) Routinearbeit ab. Mit obigem Argument kannst du ja gleich jeden
als Vollidioten hinstellen, der sich seine Systeme nicht komplett von Hand
zusammenstellt.
Und wenn jeder derart eigenwillige Lizenzen wie DJB macht, dann hat man
irgendwann wieder die Situation, dass man fast alles von Hand machen muss. Das
kann doch wohl nicht das Ziel sein, oder?
Das hat nichts mit unfähig sein oder nicht trauen zu tun. Ich traue mir zu,
ein System von Hand aufzubauen und habe dies auch schon getan. Ist 'ne lustige
Fingerübung. Aber damit will ich nicht tagtäglich meine Zeit verschwenden, da
habe ich durchaus wichtigeres zu tun.
--
Until the next mail...,
Stefan.
Felix von Leitner
> > Klimmzüge?
> > Wovon sprichst du?
> Den ganzen Kram unter <some-tmpdir>/usr installieren, und dann
> den Inhalt von <some-tmpdir> in ein Paket (deb, rpm oder was
> auch immer) zu wickeln. Und zwar so daß man hinterher passende
> Pfade in den Binaries hat. Achja: das ganze sollte möglichst
> auch für normale user funkionieren.
Trivialer Patch an install.c
> > echo /opt/djbdns > conf-cc && make && sudo make setup && cd / && \
> > tar czf tmp/djbdns-bin.tar.gz opt/djbdns etc/dnsroots.global
> Ich möchte auch selbstgebaute Pakete im Paketmanagement der
> Distribution drinhaben. Ein tarball leistet das nicht.
Wenn du dir zusätzlich Schmerzen machen möchtest -- bitte.
Der Grund, wieso djb nicht möchte, daß Distributionen seine Pfade
ändern, ist übrigens genau dieser: damit Distributionstools nicht mit
einem Auspacken eines frischen Sourcetrees von djbdns kollidieren.
Deine Schmerzen machst du dir komplett selber. Ich kann das nicht
nachvollziehen, aber wenn du das Bedürfnis verspürst, kannst du das auch
mit djbdns machen.
> > Sieht das irgendwie komplex oder schwierig aus?
> Es macht nicht das was ich will. Das sieht eher so aus:
>
> %build
> echo <some-tmpdir>/usr > conf-cc
> make install
> cp install buildroot-install
> echo /usr > conf-cc
> make
>
> %install
> cp buildroot-install install
> make setup
Die Dateiliste kannst du trivial mit sed aus hier.c extrahieren.
Wenn dir das nicht reicht, dann kannst du dir auch beliebig viel Streß
machen, aber es ist unredlich, diesen Streß djb anzuhängen.
> Bei fast allen anderen Softwarepaketen kann man einfach
> ein "make DESTDIR=<some-tmpdir> install" oder
> "make prefix=<some-tmpdir>/usr install" machen um nach dem
> durchbauen den Kram nach <some-tmpdir> statt in's laufende
> System zu installieren.
Das kann man tun, aber djb benutzt kein System-install
(und ist damit schneller und portabler).
> > > Aber ich wäre nicht direkt böse darüber wenn mir die
> > > Distribution das abnehmen würde.
> > Wende dich an deine Distribution, nicht an djb.
> *Mööp*. Geht eben nicht wegen der Lizenz. Goto ein paar
> Postings zurück im Thread ...
Das mit der Lizenz ist ein unzulässiges Scheinargument.
Felix
Gerd Knorr
> >erfordert). Aber ich wäre nicht direkt böse darüber wenn mir die
> >Distribution das abnehmen würde.
>
> Soll sie Dich vielleicht noch an der Hand nehmen?
Ja. Ein nettes debconf drumherum wäre nicht schlecht.
> Wenn sich ''Unix-Admins'' heutzutage nicht mal mehr trauen, Software aus
> den Quellen anzupassen und zu installieren - dann gute Nacht.
Was heißt hier nicht trauen? Ich bin einfach nur zu faul dazu. Ich hab
mir mal ein eigenes Linux from scratch zusammencompiliert, ist ja nicht
so daß ich das nicht kann. Ich muß das aber trotzdem nicht jeden Tag
haben. Das wird mit der Zeit nämlich langweilig und hält einem vom News
lesen ab. 'ne Distribution ist ja genau dazu da, einem diesen ganzen
Kram abzunehmen. Was ist schlecht daran djbdns gleich ready-to-go mit
dabei zu haben?
Lutz Donnerhacke
>Lutz Donnerhacke (lu...@iks-jena.de) wrote:
>> Contests im Bereich von Security Produkten sind BAD(tm).
>> djb Software hat ein wesentliches Manko: Es konvertiert Nutzer zu Fanatikern.
>>
>> djbdns ist in etwas anders gelagert. Er versucht nicht, einen unfairen
>> Contest anzubieten und dann zu bahaupten, es wäre deswegen sicher.
>
>Stichwort "quality game" im Frage- und Antwort-Spiel von P.V.
>(Qualität als Spiel anzusehen ist nicht meine Idee):
>
>> Q: Other DNS software publishers promise 0 defects and even offer rewards.
>> Why can't ISC seem to compete at the quality game?
>> A: If someone else's DNS software ever runs on 80% of the Internet's name
>> servers and is shipped in source form that can run on a dozen or more
>> architectures, ISC will certainly feel that we have much to learn from
>> the authors of that software.
>
>Ich interpretiere das so: wir beherrschen den Markt, was schert uns
>der Rest. Im übrigen verwandeln sich mit dem Herrenclub gerade
>Bugs in Bucks, warum sollte er darauf verzichten :-)
Ich promote nicht BIND, ich opponiere gegenüber Fanatikern. Wie man lesen
kann: Zu Recht.
Marc Haber
>Gerd Knorr <gkn...@berlinonline.de> wrote:
>>Ich kann kein "apt-get install djbdns" machen.
>
>Dann compilier Dir das mit Deinen Einstellungen lokal und bau Dein eigenes
>.deb draus. Das ist ja nun wirklich alles andere als schwer.
Dieses .deb darf ich dann aber nicht auf Systemen installieren, die
ich verkaufe, bzw. die bei anderen stehen. Also nicht auf > 80 % der
Systeme, die ich betreue. Damit ist's für mich unbrauchbar.
Marc Haber
>> >Wieso kannst du eigentlich nicht aufhören, die Lüge zu verbreiten, daß
>> >djb's Lizenz dir erschwert, auf deinem System die Pfade zu ändern?
>> "Meine" Systeme sind auch Systeme, die an unsere Kunden verkauft
>> (sic!) wurden, und die wir nach Installation weitermanagen.
>
>Da die Software eh kostenlos abrufbar ist, verkaufst du nicht die
>Software, sondern den Installationsservice, d.h. du installierst auf dem
>Rechner des Kunden.
Das ist eine kreative Interpretation der Lizenz, zu der ich schon zu
Microsoftzeiten nicht bereit war. Wenn er das nicht will, dann will er
es nicht - und ich werde einen Deibel tun, seinen Willen zu
unterlaufen. Wenn er partout möchte, dass seine exzellente Software
nicht eingesetzt wird, dann kann er das haben.
>Die Installation von djbdns läßt sich als eine Zeile in der Shell
>ausdrücken. Wenn dir das zuviel Aufwand ist, hast du die Schmerzen von
>BIND verdient. Und zwar alle.
BIND macht in meiner Umgebung so gut wie keine Schmerzen.
Glücklicherweise, denn eine ernstzunehmende Alternative gibt es nicht.