Hello all, after a useless discussion on the opensuse ML I had to find out that they buried the removal news of libwrap last year in some half-sentence. So this is unfortunately pretty late for the topic. Nevertheless it is pretty obvious that you did not get any feedback from people using ssh over decades in server-administration. Let me make a clear point: libwrap removal was a pretty bad idea. It is a well-used security feature that is _not_ replaceable by your match-statement. As a first libwrap has features that match does not have. Second libwrap is easy-to-use and offers a possibility to make securtiy adjustments in _one_ file for nearly all services, whereas you propose to edit proprietary config files of all services with proprietary config statements for each service. If you have 20 of those you end up editing 20 config files in 20 different places in the fs with at least 20 different statements. This is _shit_. I am not against your match statement, leave it as is. But do not drop libwrap. If you deny libwrap somebody will fork the project for sure. libwrap has not changed for years because it simply works. And firewall rules are no replacement for it, because libwrap is not only an ip filter. It seems you did not know that when you made the wrong decision. Please cc me in case as I am not reading the list. -- Regards, Stephan
Stephan von Krawczynski wrote:> it is pretty obviousI guess you're not only not subscribed to the development list, but you seem to also not have looked at the list archives. You can only seem like a troll if you act as if you know best but in fact you are wrong. It's up to you whether you want to risk that of course, but it's dangerous for your case.> libwrap removal was a pretty bad idea.There was discussion. I recommend that you look for it in the archives, so that you can join the discussion without repeating what has already been said.> _not_ replaceable by your match-statement.This rhetoric makes it sound like it is very important for you to distance yourself from the OpenSSH developers. That may not be such a great strategy when you want someone to do something for you. The rationale is that firewall rules can replace libwrap and that removing libwrap removes a significant attack surface exposed to the network.> make securtiy adjustments in _one_ file for nearly all services > whereas you propose to edit proprietary config files of all > services with proprietary config statements for each service.If you actually care about security then don't you need to hand-craft those config files regardless of libwrap? And 20 services on one system? That seems a high number to me.> If you deny libwrapThat is already the case.> somebody will fork the project for sure.Go for it. I think uptake will be limited. I think your best bet will be for you to contribute modifications to your prefered distribution.> you made the wrong decision. Please cc me in case as I am not > reading the list.If you had been reading the list you would already have known everything I wrote in this email. //Peter
On Wed, 20 May 2015 14:46:57 +0200 Peter Stuge <peter at stuge.se> wrote:> Stephan von Krawczynski wrote: > > it is pretty obvious > > I guess you're not only not subscribed to the development list, but > you seem to also not have looked at the list archives. > > You can only seem like a troll if you act as if you know best but > in fact you are wrong. It's up to you whether you want to risk that > of course, but it's dangerous for your case.Are you already preparing for having no arguments?> > _not_ replaceable by your match-statement. > > This rhetoric makes it sound like it is very important for you to > distance yourself from the OpenSSH developers. That may not be such > a great strategy when you want someone to do something for you. > > The rationale is that firewall rules can replace libwrap and that > removing libwrap removes a significant attack surface exposed to the > network.Show me this as an example of your firewall skills and replace this hosts.allow entry: sshd: .... : spawn (echo -e "%u@%h[%a] on `/bin/date`" to %d connected me | /bin/mail -s "hosts.allow entry XYZ" root) & : ALLOW This is only an example code, of course.> > somebody will fork the project for sure. > > Go for it. I think uptake will be limited. I think your best bet will > be for you to contribute modifications to your prefered distribution.Negative. Wait and see.> > you made the wrong decision. Please cc me in case as I am not > > reading the list. > > If you had been reading the list you would already have known > everything I wrote in this email. > > > //PeterI saw the wrong outcome of it, and will reverse it. -- Regards, Stephan
On Wednesday 20 May 2015 14:46:57 Peter Stuge wrote:> Stephan von Krawczynski wrote: > > it is pretty obvious > > I guess you're not only not subscribed to the development list, but > you seem to also not have looked at the list archives. > > You can only seem like a troll if you act as if you know best but > in fact you are wrong. It's up to you whether you want to risk that > of course, but it's dangerous for your case. > > > libwrap removal was a pretty bad idea. > > There was discussion. I recommend that you look for it in the > archives, so that you can join the discussion without repeating > what has already been said. > > > _not_ replaceable by your match-statement. > > This rhetoric makes it sound like it is very important for you to > distance yourself from the OpenSSH developers. That may not be such > a great strategy when you want someone to do something for you. > > The rationale is that firewall rules can replace libwrap and that > removing libwrap removes a significant attack surface exposed to the > network. > > > make securtiy adjustments in _one_ file for nearly all services > > whereas you propose to edit proprietary config files of all > > services with proprietary config statements for each service. > > If you actually care about security then don't you need to hand-craft > those config files regardless of libwrap? > > And 20 services on one system? That seems a high number to me. > > > If you deny libwrap > > That is already the case. > > > somebody will fork the project for sure. > > Go for it. I think uptake will be limited. I think your best bet will > be for you to contribute modifications to your prefered distribution. > > > you made the wrong decision. Please cc me in case as I am not > > reading the list. > > If you had been reading the list you would already have known > everything I wrote in this email. >Please ignore this troll! He already polluted the opensuse mailing list with his ignorant postings. Karsten. -- Sweet sixteen is beautiful Bess, And her voice is changing -- from "No" to "Yes".
I saw the abusive email you sent to me the other day. It's basically the perfect way to get developers to ignore you, which is exactly what I'm going to do now. On Wed, 20 May 2015, Stephan von Krawczynski wrote:> Hello all, > > after a useless discussion on the opensuse ML I had to find out that they > buried the removal news of libwrap last year in some half-sentence. So this is > unfortunately pretty late for the topic. Nevertheless it is pretty obvious > that you did not get any feedback from people using ssh over decades in > server-administration. Let me make a clear point: libwrap removal was a pretty > bad idea. It is a well-used security feature that is _not_ replaceable by your > match-statement. As a first libwrap has features that match does not have. > Second libwrap is easy-to-use and offers a possibility to make securtiy > adjustments in _one_ file for nearly all services, whereas you propose to edit > proprietary config files of all services with proprietary config statements > for each service. If you have 20 of those you end up editing 20 config files > in 20 different places in the fs with at least 20 different statements. This > is _shit_. I am not against your match statement, leave it as is. But do not > drop libwrap. If you deny libwrap somebody will fork the project for sure. > libwrap has not changed for years because it simply works. And firewall rules > are no replacement for it, because libwrap is not only an ip filter. It seems > you did not know that when you made the wrong decision. Please cc me in case > as I am not reading the list. > > -- > Regards, > Stephan > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >
On Thu, 21 May 2015 08:51:59 +1000 (AEST) Damien Miller <djm at mindrot.org> wrote:> I saw the abusive email you sent to me the other day. It's basically > the perfect way to get developers to ignore you, which is exactly what > I'm going to do now.I have not really expected a positive answer from someone removing a perfectly well ten-liner from code just to make thousands of people having to completely change their configs and possibly add more then the ten lines to other configs. That is not software development, that is sabotage. Thanks for top-posting, shows your true commitment.> On Wed, 20 May 2015, Stephan von Krawczynski wrote: > > > Hello all, > > > > after a useless discussion on the opensuse ML I had to find out that they > > buried the removal news of libwrap last year in some half-sentence. So this is > > unfortunately pretty late for the topic. Nevertheless it is pretty obvious > > that you did not get any feedback from people using ssh over decades in > > server-administration. Let me make a clear point: libwrap removal was a pretty > > bad idea. It is a well-used security feature that is _not_ replaceable by your > > match-statement. As a first libwrap has features that match does not have. > > Second libwrap is easy-to-use and offers a possibility to make securtiy > > adjustments in _one_ file for nearly all services, whereas you propose to edit > > proprietary config files of all services with proprietary config statements > > for each service. If you have 20 of those you end up editing 20 config files > > in 20 different places in the fs with at least 20 different statements. This > > is _shit_. I am not against your match statement, leave it as is. But do not > > drop libwrap. If you deny libwrap somebody will fork the project for sure. > > libwrap has not changed for years because it simply works. And firewall rules > > are no replacement for it, because libwrap is not only an ip filter. It seems > > you did not know that when you made the wrong decision. Please cc me in case > > as I am not reading the list. > > > > -- > > Regards, > > Stephan > > _______________________________________________ > > openssh-unix-dev mailing list > > openssh-unix-dev at mindrot.org > > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > >-- Regards, Stephan