On 01/09/2012 12:03 PM, Ed Marshall wrote:
No, I most certainly did not write the quoted statement.
Sorry, you are right, you responded to that statement made by others. I
apologize.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Mon, Jan 9, 2012 at 5:03 PM, Przemek Klosowski <
przemek.klosow...@nist.gov> wrote:
> On 01/09/2012 09:08 AM, Matthew Garrett wrote:
>
>> On Mon, Jan 09, 2012 at 02:42:10AM +0100, Reindl Harald wrote:
>>
>> no, maybe you should read AND try to understand
>>>
>>
>> This kind of behaviour isn't
On Mon, Jan 09, 2012 at 11:03:43AM -0500, Przemek Klosowski wrote:
> On 01/09/2012 09:08 AM, Matthew Garrett wrote:
> >On Mon, Jan 09, 2012 at 02:42:10AM +0100, Reindl Harald wrote:
> >
> >>no, maybe you should read AND try to understand
> >
> >This kind of behaviour isn't acceptable within the pro
No, I most certainly did not write the quoted statement.
(My contribution has solely been suggesting that they get upstream on board;
or, failing that, find a convincing argument for the Fedora package maintainer
to diverge from upstream.)
--
Ed Marshall
http://esm.logic.net/
On Jan 9, 2012,
On 01/09/2012 09:08 AM, Matthew Garrett wrote:
On Mon, Jan 09, 2012 at 02:42:10AM +0100, Reindl Harald wrote:
no, maybe you should read AND try to understand
This kind of behaviour isn't acceptable within the project. Treat your
fellow community members with respect. You're expected to follow
On Mon, Jan 09, 2012 at 02:42:10AM +0100, Reindl Harald wrote:
> no, maybe you should read AND try to understand
This kind of behaviour isn't acceptable within the project. Treat your
fellow community members with respect. You're expected to follow the
Fedora Code of Conduct
(http://fedoraproj
On Mon, Jan 9, 2012 at 9:07 AM, Reindl Harald wrote:
>
>
> Am 09.01.2012 07:27, schrieb Ed Marshall:
>> On Sun, Jan 8, 2012 at 5:42 PM, Reindl Harald wrote:
>>> if a software-package, information, disclosure is NOT NEEDED it has
>>> to be disabled - again: take some security education!
>>
>> And,
Am 09.01.2012 07:27, schrieb Ed Marshall:
> On Sun, Jan 8, 2012 at 5:42 PM, Reindl Harald wrote:
>> if a software-package, information, disclosure is NOT NEEDED it has
>> to be disabled - again: take some security education!
>
> And, there we go.
>
> Convince upstream to change their behavior
On Sun, Jan 8, 2012 at 5:42 PM, Reindl Harald wrote:
> if a software-package, information, disclosure is NOT NEEDED it has
> to be disabled - again: take some security education!
And, there we go.
Convince upstream to change their behavior (but, read their FAQ on
this exact question first, and t
Am 09.01.2012 02:36, schrieb Nathanael Noblet:
> On 01/08/2012 04:24 PM, Reindl Harald wrote:
>> and you think that some random examples prove anything?
>> some webserver logs are showing nothing about real exploits
>>
>> there was and there will be exploits you will never see
>> in your webserve
On 01/08/2012 04:24 PM, Reindl Harald wrote:
and you think that some random examples prove anything?
some webserver logs are showing nothing about real exploits
there was and there will be exploits you will never see
in your webserver-log because if they worked CODE was
executed in the context o
Am 08.01.2012 23:16, schrieb Nathanael Noblet:
> So from my logs. Not a probe first, just plain trying to get data using a
> hopeful exploit. They don't care what
> version of anything I'm running.
>
> I realize it looks like they got the files they wanted, but in reality it
> ignored the requ
On 01/08/2012 01:46 PM, Reindl Harald wrote:
Am 08.01.2012 21:06, schrieb Ian Pilcher:
On 01/06/2012 11:31 PM, Reindl Harald wrote:
yes, i know it is security by obscurity
but does it hurt?
Yes, it hurts.
It hurts every time we make life a little more difficult to satisfy
someone's misguid
Am 08.01.2012 21:06, schrieb Ian Pilcher:
> On 01/06/2012 11:31 PM, Reindl Harald wrote:
>> yes, i know it is security by obscurity
>> but does it hurt?
>
> Yes, it hurts.
>
> It hurts every time we make life a little more difficult to satisfy
> someone's misguided idea of "securitee". I refer
On 01/06/2012 11:31 PM, Reindl Harald wrote:
> yes, i know it is security by obscurity
> but does it hurt?
Yes, it hurts.
It hurts every time we make life a little more difficult to satisfy
someone's misguided idea of "securitee". I refer you to the
Transportation Security Administration if you
On Sat, Jan 7, 2012 at 5:24 AM, Bruno Wolff III wrote:
> On Sat, Jan 07, 2012 at 05:09:42 +0100,
> Reindl Harald wrote:
>>
>> however - why do we spit the current running versions to everyone?
>
> It can help when trouble shooting problems. The current version isn't
> really that helpful to atta
Am 07.01.2012 16:02, schrieb Kevin Kofler:
> Reindl Harald wrote:
>> but i also know that from "SSH-2.0-OpenSSH_5.8" only "SSH-2.0"
>> is relevant for clients
>
> "SSH-2.0" brings no information at all. ANY even remotely current SSH server
> will report "SSH-2.0". That doesn't tell you anything
On Sat, Jan 07, 2012 at 15:55:34 +0100,
Reindl Harald wrote:
>
> i, and only i am responsible for the machines so why
> do i not have a option only "SSH-2.0-OpenSSH" provide
> to a anonymous client?
You do have that option. That's the nice thing about free software. You
can rebuild the rpm wit
Reindl Harald wrote:
> but i also know that from "SSH-2.0-OpenSSH_5.8" only "SSH-2.0"
> is relevant for clients
"SSH-2.0" brings no information at all. ANY even remotely current SSH server
will report "SSH-2.0". That doesn't tell you anything about implementation-
specific behavior an SSH client
Am 07.01.2012 15:44, schrieb Sam Varshavchik:
>> no, one keys of security is to provide as less informations as
>> absolutely necessary, not only for sshd, for every single
>> service
>>
>> in the best case no single foreign person has an idea
>> what software you are currently running, not what
Am 07.01.2012 15:40, schrieb Kevin Kofler:
> Reindl Harald wrote:
>> if you have a big customer which hires a 3rd party auditor
>> you are NOT in the poisiton to give such arguments or
>> you can give them but you can not change ANYTHING in
>> the fact that finally "fix it or shutdown the service
Reindl Harald writes:
Am 07.01.2012 08:02, schrieb Digimer:
>> i know about the pros and cons for obscurity
>>
>> but i also know that from "SSH-2.0-OpenSSH_5.8" only "SSH-2.0"
>> is relevant for clients and having backports in mind this must
>> be the truth because if the whole version would
Reindl Harald writes:
Am 07.01.2012 06:35, schrieb Digimer:
>> if you have a big customer which hires a 3rd party auditor
>> you are NOT in the poisiton to give such arguments or
>> you can give them but you can not change ANYTHING in
>> the fact that finally "fix it or shutdown the service"
>>
Reindl Harald wrote:
> if you have a big customer which hires a 3rd party auditor
> you are NOT in the poisiton to give such arguments or
> you can give them but you can not change ANYTHING in
> the fact that finally "fix it or shutdown the service"
> is what you have to do
They need to fire the a
On Sat, 7 Jan 2012, Reindl Harald wrote:
would it not be a good idea to NOT disclosure service versions?
https://bugzilla.redhat.com/show_bug.cgi?id=718133
you will more and more have the "problem" of 3rd party
security scans to your servers and currently in the case
of openssh the only solutio
* Reindl Harald [07/01/2012 08:37] :
>
> however - why do we spit the current running versions to everyone?
In the case of openssh, it's to allow the client to work around known bugs
in the server. In other cases, it's simply of case of not wanting to patch
gratuitously packages.
Emmanuel
--
dev
Once upon a time, Reindl Harald said:
> no, one keys of security is to provide as less informations as
> absolutely necessary, not only for sshd, for every single
> service
That's a key for a false sense of security.
> in the best case no single foreign person has an idea
> what software you are
Once upon a time, Reindl Harald said:
> but i also know that from "SSH-2.0-OpenSSH_5.8" only "SSH-2.0"
> is relevant for clients
That's not actually true for SSH. The additional bits can be used to
work around known problems with specific versions.
--
Chris Adams
Systems and Network Administr
Once upon a time, Reindl Harald said:
> Am 07.01.2012 06:35, schrieb Digimer:
> > If you have a "security expert" who can't grasp the concept of
> > back-ported bug fixes, and is unwilling to test for specific
> > vulnerabilities' existence, it's time to get a new expert.
>
> you are missing the
Am 07.01.2012 08:02, schrieb Digimer:
>> i know about the pros and cons for obscurity
>>
>> but i also know that from "SSH-2.0-OpenSSH_5.8" only "SSH-2.0"
>> is relevant for clients and having backports in mind this must
>> be the truth because if the whole version would matter all
>> LTS distrib
On 01/07/2012 01:59 AM, Reindl Harald wrote:
>
>
> Am 07.01.2012 07:52, schrieb Digimer:
>> On 01/07/2012 01:02 AM, Reindl Harald wrote:
>>> Am 07.01.2012 06:35, schrieb Digimer:
> if you have a big customer which hires a 3rd party auditor
> you are NOT in the poisiton to give such argume
Am 07.01.2012 07:52, schrieb Digimer:
> On 01/07/2012 01:02 AM, Reindl Harald wrote:
>> Am 07.01.2012 06:35, schrieb Digimer:
if you have a big customer which hires a 3rd party auditor
you are NOT in the poisiton to give such arguments or
you can give them but you can not change AN
On 01/07/2012 01:02 AM, Reindl Harald wrote:
> Am 07.01.2012 06:35, schrieb Digimer:
>>> if you have a big customer which hires a 3rd party auditor
>>> you are NOT in the poisiton to give such arguments or
>>> you can give them but you can not change ANYTHING in
>>> the fact that finally "fix it or
On Fri, Jan 6, 2012 at 10:02 PM, Reindl Harald wrote:
> you are missing the point A BIG CUSTOMER has a security-expert
And you, as a trusted vendor, have an opportunity to educate your
customer about their security expert, and about how the Fedora project
works.
Fedora's stance is consistent wit
On 6 January 2012 22:31, Reindl Harald wrote:
>
> Am 07.01.2012 06:13, schrieb Stephen John Smoogen:
>> On 6 January 2012 21:46, Kevin Kofler wrote:
>>> Reindl Harald wrote:
would it not be a good idea to NOT disclosure service versions?
https://bugzilla.redhat.com/show_bug.cgi?id=71813
Am 07.01.2012 06:35, schrieb Digimer:
>> if you have a big customer which hires a 3rd party auditor
>> you are NOT in the poisiton to give such arguments or
>> you can give them but you can not change ANYTHING in
>> the fact that finally "fix it or shutdown the service"
>> is what you have to do
>
On 01/07/2012 12:31 AM, Reindl Harald wrote:
>
> Am 07.01.2012 06:13, schrieb Stephen John Smoogen:
>> On 6 January 2012 21:46, Kevin Kofler wrote:
>>> Reindl Harald wrote:
would it not be a good idea to NOT disclosure service versions?
https://bugzilla.redhat.com/show_bug.cgi?id=718133
Am 07.01.2012 06:13, schrieb Stephen John Smoogen:
> On 6 January 2012 21:46, Kevin Kofler wrote:
>> Reindl Harald wrote:
>>> would it not be a good idea to NOT disclosure service versions?
>>> https://bugzilla.redhat.com/show_bug.cgi?id=718133
>>>
>>> you will more and more have the "problem" of
On 6 January 2012 21:46, Kevin Kofler wrote:
> Reindl Harald wrote:
>> would it not be a good idea to NOT disclosure service versions?
>> https://bugzilla.redhat.com/show_bug.cgi?id=718133
>>
>> you will more and more have the "problem" of 3rd party
>> security scans to your servers and currently
On 01/06/2012 11:09 PM, Reindl Harald wrote:
> would it not be a good idea to NOT disclosure service versions?
> https://bugzilla.redhat.com/show_bug.cgi?id=718133
>
> you will more and more have the "problem" of 3rd party
> security scans to your servers and currently in the case
> of openssh the
Reindl Harald wrote:
> would it not be a good idea to NOT disclosure service versions?
> https://bugzilla.redhat.com/show_bug.cgi?id=718133
>
> you will more and more have the "problem" of 3rd party
> security scans to your servers and currently in the case
> of openssh the only solution is to tka
On Sat, Jan 07, 2012 at 05:09:42 +0100,
Reindl Harald wrote:
>
> however - why do we spit the current running versions to everyone?
It can help when trouble shooting problems. The current version isn't
really that helpful to attackers anyway. It's about as easy to just to try
an exploit as it
would it not be a good idea to NOT disclosure service versions?
https://bugzilla.redhat.com/show_bug.cgi?id=718133
you will more and more have the "problem" of 3rd party
security scans to your servers and currently in the case
of openssh the only solution is to tkae the F16-src-rpm
and rebuild it
43 matches
Mail list logo
