On 12/11/2013 11:00 PM, Kevin Kofler wrote:
Brendan Jones wrote:
What is the best way to handle this case:
qWarning(QObject::tr("Client name '%1' occupied.").arg(name).toUtf8());
something like, or can I make it simpler:
qWarning("%s",qPrintable(QObject::tr("Client name '%1'
occupied.").arg(n
On Tue, Dec 10, 2013 at 09:44:43PM +0100, Mattias Ellert wrote:
> tis 2013-12-10 klockan 12:18 -0500 skrev Darryl L. Pierce:
>
> > > Of all the packages I
> > > maintain, only one was affected by this issue. That one was easily
> > > solvable by deleting the bundled swig generated code in the sour
Brendan Jones wrote:
> What is the best way to handle this case:
>
> qWarning(QObject::tr("Client name '%1' occupied.").arg(name).toUtf8());
>
> something like, or can I make it simpler:
>
> qWarning("%s",qPrintable(QObject::tr("Client name '%1'
> occupied.").arg(name).toUtf8()));
Use one of:
q
tis 2013-12-10 klockan 12:18 -0500 skrev Darryl L. Pierce:
> > Of all the packages I
> > maintain, only one was affected by this issue. That one was easily
> > solvable by deleting the bundled swig generated code in the sources and
> > have the build regenerate it with a newer swig version that do
On 12/06/2013 08:11 PM, Kevin Kofler wrote:
Adam Jackson wrote:
On Fri, 2013-12-06 at 02:21 +0100, Kevin Kofler wrote:
QString line;
line.fill( '-', 60 );
qDebug( line.ascii() );
As you can see, the format string being passed here is provably constant.
So fix the compiler.
> 1. There are legitimate use-cases where GCC's assumption does not hold, .e.g.:
>
> #include
>
> void foo( int a )
> {
> char hello0[] = "hello0";
foo.c line 5: warning: 'const' omitted
> char hello1[] = "hello1";
foo.c line 6: warning: 'const' omitted
>
> char *ptr;
foo.c line 8: warn
On Sat, Dec 07, 2013 at 07:12:03AM +0100, Mattias Ellert wrote:
> fre 2013-12-06 klockan 15:06 -0500 skrev Darryl L. Pierce:
> > Additionally, some code (like my package, qpid-cpp) uses code that's
> > generated by another app like Swig. We have no control over what that
> > code is. So enabling th
On Fri, Dec 06, 2013 at 03:58:21PM -0500, David Malcolm wrote:
> On Fri, 2013-12-06 at 15:06 -0500, Darryl L. Pierce wrote:
> > Additionally, some code (like my package, qpid-cpp) uses code that's
> > generated by another app like Swig. We have no control over what that
> > code is. So enabling thi
Once upon a time, Chris Adams said:
> Aside from everything else, using the printf() family of functions when
> you don't want formatted output is bad practice. There's really no
> excuse for calling printf(foo); if you don't want formatted output (i.e.
> you don't pass a format string with addit
Once upon a time, Ralf Corsepius said:
> printf( ptr );
Aside from everything else, using the printf() family of functions when
you don't want formatted output is bad practice. There's really no
excuse for calling printf(foo); if you don't want formatted output (i.e.
you don't pass a format st
On 12/10/2013 04:35 PM, Miloslav Trmač wrote:
On Tue, Dec 10, 2013 at 3:50 PM, Kevin Kofler wrote:
drago01 wrote:
On Tue, Dec 10, 2013 at 3:00 AM, Kevin Kofler
-Werror=format-security removes the functionality of building format strings
at runtime, and there are legitimate uses for such f
On Tue, Dec 10, 2013 at 3:50 PM, Kevin Kofler wrote:
> drago01 wrote:
>
>> On Tue, Dec 10, 2013 at 3:00 AM, Kevin Kofler
>> wrote:
>>> [...] and removes functionality
>>
>> No it does not.
>
> Yes, it does, see my example:
> | a printf wrapper for logging which adds a timestamp in front of the
>
drago01 wrote:
> On Tue, Dec 10, 2013 at 3:00 AM, Kevin Kofler
> wrote:
>> [...] and removes functionality
>
> No it does not.
Yes, it does, see my example:
| a printf wrapper for logging which adds a timestamp in front of the
| format string, e.g.
| log("processed %d items", foo);
| which woul
On Tue, Dec 10, 2013 at 3:00 AM, Kevin Kofler wrote:
> [...] and removes functionality
No it does not.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On Mon, Dec 09, 2013 at 03:01:55PM -0800, Les Howell wrote:
> unless something has changed recently fputs and puts just like gets and
> fgets have been deprecated and are discouraged due to potential security
> issues.
That is wrong. Only gets is deprecated (removed in C11, obsolescent in
POSIX
Adam Jackson wrote:
> Allow me to suggest something that really shouldn't be controversial,
> but probably is, because this is the internet: standards compliance for
> its own sake is not actually worthwhile.
Tell that to the GCC (especially g++) developers who keep breaking backwards
compatibili
Les Howell wrote:
>> printf("%s", string) is inefficient. In
>> this case, it would be better to use puts/fputs.
>>
>unless something has changed recently fputs and puts just like gets
>and fgets have been deprecated and are discouraged due to potential
>security issues.
gets is horribly inse
On 09/12/13 23:01, Les Howell wrote:
unless something has changed recently fputs and puts just like gets and
fgets have been deprecated and are discouraged due to potential security
issues.
Nonsense.
The reason gets is dangerous is because it doesn't take a buffer size so
will continue read
On 10.12.2013 00:01, Les Howell wrote:
> On Mon, 2013-12-09 at 15:59 -0700, Rich Megginson wrote:
>> On 12/09/2013 03:33 PM, Przemek Klosowski wrote:
>>
>>> On 12/06/2013 09:21 AM, Ralf Corsepius wrote:
>>>
printf(string) is legitimate C, forcing "printf("%s", string) is
just silly.
On Mon, 2013-12-09 at 15:59 -0700, Rich Megginson wrote:
> On 12/09/2013 03:33 PM, Przemek Klosowski wrote:
>
> > On 12/06/2013 09:21 AM, Ralf Corsepius wrote:
> >
> > >
> > > printf(string) is legitimate C, forcing "printf("%s", string) is
> > > just silly.
> > >
> > My apologies for being re
On 12/09/2013 03:33 PM, Przemek Klosowski wrote:
On 12/06/2013 09:21 AM, Ralf Corsepius wrote:
printf(string) is legitimate C, forcing "printf("%s", string) is just
silly.
My apologies for being repetitive, but the original point is that
printf(string) is insecure unless you can guarantee t
On Sun, 2013-12-08 at 01:17 +0100, Kevin Kofler wrote:
> Michael scherer wrote:
> > There is enough software not building anymore and dropped after mass
> > rebuild to show that such problem are not really so uncommon.
>
> … the difference is that in this case, the offending code is actually
> pe
On 12/06/2013 09:21 AM, Ralf Corsepius wrote:
printf(string) is legitimate C, forcing "printf("%s", string) is just
silly.
My apologies for being repetitive, but the original point is that
printf(string) is insecure unless you can guarantee that you control
'string' now and forever. Also,
Michael scherer wrote:
> That's already part of the life of packagers. For example, suddenly, gcc
> decide to be stricter and suddenly, some VCS written in C++ decide to not
> compile anymore, so you have to spend 1 full day just to make it compile.
> ( of course, totally fictious example that didn
On 12/07/2013 03:39 AM, Reindl Harald wrote:
Am 06.12.2013 15:59, schrieb Ralf Corsepius:
On 12/06/2013 02:57 PM, Reindl Harald wrote:
if arbitary users are allowed to call CLI applications from a webserver
?!? Calling cli-tools underneath of webservices is the norm on many webservers.
Of
fre 2013-12-06 klockan 15:06 -0500 skrev Darryl L. Pierce:
> On Fri, Dec 06, 2013 at 02:27:05AM +0100, Kevin Kofler wrote:
> > Michael scherer wrote:
> > > Let's rather ask the contrary, why is this so much a issue to communicate
> > > with upstream to fix things, and add patches ?
> >
> > The vas
Am 06.12.2013 15:59, schrieb Ralf Corsepius:
> On 12/06/2013 02:57 PM, Reindl Harald wrote:
>> if arbitary users are allowed to call CLI applications from a webserver
> ?!? Calling cli-tools underneath of webservices is the norm on many
> webservers. Often these calls are wrapped into
> scripti
On Thu, Dec 05, 2013 at 07:40:36PM -0600, mrnuke wrote:
> On 12/05/2013 11:38 AM, Michael scherer wrote:
> > On Wed, Dec 04, 2013 at 08:25:54PM -0600, mrnuke wrote:
> >>
> >> This change is Sofa King stupid. Why couldn't we have just enabled the
> >> warning without turning it into an error, THEN l
On Fri, 2013-12-06 at 15:06 -0500, Darryl L. Pierce wrote:
> On Fri, Dec 06, 2013 at 02:27:05AM +0100, Kevin Kofler wrote:
> > Michael scherer wrote:
> > > Let's rather ask the contrary, why is this so much a issue to communicate
> > > with upstream to fix things, and add patches ?
> >
> > The vas
On Fri, Dec 06, 2013 at 02:27:05AM +0100, Kevin Kofler wrote:
> Michael scherer wrote:
> > Let's rather ask the contrary, why is this so much a issue to communicate
> > with upstream to fix things, and add patches ?
>
> The vast majority of those warnings are actually false positives, not actual
On Fri, Dec 06, 2013 at 08:02:06PM +0100, Kevin Kofler wrote:
> * translatable format strings, e.g.
> printf(translate("processed %d items"), foo);
Translatable strings are handled just fine.
Try e.g.:
extern int my_printf (void *my_object, const char *my_format, ...)
__attribute__ ((format (
On Fri, Dec 6, 2013 at 8:02 PM, Kevin Kofler wrote:
> See e.g. the examples I have given in the FESCo ticket:
> * a printf wrapper for logging which adds a timestamp in front of the
> format string, e.g.
> log("processed %d items", foo);
> which would be printed as
> 2013-12-06 19:00:00: p
On Fri, Dec 06, 2013 at 07:57:04PM +0100, Kevin Kofler wrote:
> Ralf Corsepius wrote:
>
> > On 12/06/2013 12:26 PM, Dhiru Kholia wrote:
> >> There is still plenty of time left before this flag is even enabled in
> >> rawhide configuration by default.
> > IMO, this plan has failed - period.
>
> +1
On Fri, Dec 6, 2013 at 4:50 PM, Ralf Corsepius wrote:
> On 12/06/2013 12:26 PM, Dhiru Kholia wrote:
>>
>> On 12/06/13 at 11:57am, Reindl Harald wrote:
>>>
>>> but what is the plan if this does not work out for a unknown number
>>> of packages because upstream is not willing or able to "fix it" or
mrnuke (mr.nuke...@gmail.com) said:
> > Because packagers will just ignore it [...]
> >
> I think this is a childish argument, but let's take it. So what? You're
> going to start stepping on people's lawns and change things just because
> you want to impose your greater good?
Wow, nice mixed met
Ben Boeckel wrote:
> Use the printf attribute on the function to fix this.
That doesn't work if I have to prepend a date to my format string.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: h
Adam Jackson wrote:
> On Fri, 2013-12-06 at 02:21 +0100, Kevin Kofler wrote:
>
>> QString line;
>> line.fill( '-', 60 );
>> qDebug( line.ascii() );
>> As you can see, the format string being passed here is provably constant.
>
> So fix the compiler.
I don't think GCC will ever be a
Przemek Klosowski wrote:
> Given that pretty much all those cases can be solved by either "%s" or
>
> | __attribute__((__format__(__printf, 1, 2)));
"pretty much all" maybe, but not all!
See e.g. the examples I have given in the FESCo ticket:
* a printf wrapper for logging which adds a timesta
PS:
Przemek Klosowski wrote:
> | __attribute__((__format__(__printf, 1, 2)));
is also compiler-specific, which some upstreams also won't like. Of course,
it can be #ifdef-wrapped, but many upstreams try to avoid #ifdef as much as
possible.
Kevin Kofler
--
devel mailing list
devel@l
Ralf Corsepius wrote:
> On 12/06/2013 12:26 PM, Dhiru Kholia wrote:
>> There is still plenty of time left before this flag is even enabled in
>> rawhide configuration by default.
> IMO, this plan has failed - period.
+1
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
h
On Fri, 2013-12-06 at 02:21 +0100, Kevin Kofler wrote:
> QString line;
> line.fill( '-', 60 );
> qDebug( line.ascii() );
> As you can see, the format string being passed here is provably constant.
So fix the compiler.
- ajax
--
devel mailing list
devel@lists.fedoraproject.org
htt
On 12/06/2013 12:26 PM, Dhiru Kholia wrote:
On 12/06/13 at 11:57am, Reindl Harald wrote:
but what is the plan if this does not work out for a unknown number
of packages because upstream is not willing or able to "fix it" or
only in a later release giving that the package is not buildable
at all
On 12/06/2013 02:57 PM, Reindl Harald wrote:
Am 06.12.2013 14:08, schrieb Ralf Corsepius:
On 12/06/2013 10:43 AM, Reindl Harald wrote:
Am 06.12.2013 10:37, schrieb Ralf Corsepius:
IMO, -Wformat-security is almost negibile in comparison to these and you
are making way too much noise about it
On 12/06/2013 02:07 PM, Przemek Klosowski wrote:
On 12/05/2013 08:27 PM, Kevin Kofler wrote:
The vast majority of those warnings are actually false positives, not actual
security issues. Putting my upstream hat on, if asked to "fix" such a false
positive, I'd do one of:
(a) close the bug as INVA
Am 06.12.2013 14:08, schrieb Ralf Corsepius:
> On 12/06/2013 10:43 AM, Reindl Harald wrote:
>>
>> Am 06.12.2013 10:37, schrieb Ralf Corsepius:
> IMO, -Wformat-security is almost negibile in comparison to these and you
> are making way too much noise about it than it deserves.
htt
On 12/06/2013 10:43 AM, Reindl Harald wrote:
Am 06.12.2013 10:37, schrieb Ralf Corsepius:
IMO, -Wformat-security is almost negibile in comparison to these and you
are making way too much noise about it than it deserves.
http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=format+string [*]
Yeah,
On 12/05/2013 08:27 PM, Kevin Kofler wrote:
The vast majority of those warnings are actually false positives, not actual
security issues. Putting my upstream hat on, if asked to "fix" such a false
positive, I'd do one of:
(a) close the bug as INVALID/NOTABUG/WONTFIX or
(b) hardcode -Wno-error=for
On 12/06/2013 01:26 PM, Florian Weimer wrote:
On 12/06/2013 12:59 PM, Dhiru Kholia wrote:
Can you *really* pass a QByteArray object directly to printf (and similar
functions)?
Yes, as the format string argument, because the user-defined conversion
comparison operator to const char * kicks in.
On 12/06/2013 12:59 PM, Dhiru Kholia wrote:
Can you *really* pass a QByteArray object directly to printf (and similar
functions)?
Yes, as the format string argument, because the user-defined conversion
comparison operator to const char * kicks in.
--
Florian Weimer / Red Hat Product Securit
On 12/06/2013 12:59 PM, Dhiru Kholia wrote:
On 12/04/13 at 07:10pm, Brendan Jones wrote:
This is just a pain. Can someone explain to me why this is good?
Original Message
Subject: [Bug 1037125] hydrogen FTBFS if "-Werror=format-security" flag is
https://bugzilla.redhat.com/sh
On 12/04/13 at 07:10pm, Brendan Jones wrote:
> This is just a pain. Can someone explain to me why this is good?
>
> Original Message
> Subject: [Bug 1037125] hydrogen FTBFS if "-Werror=format-security" flag is
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1037125
Hi Brendan,
C
On 12/06/2013 12:25 PM, Brendan Jones wrote:
On 12/06/2013 11:30 AM, Adam Williamson wrote:
On Fri, 2013-12-06 at 10:37 +0100, Ralf Corsepius wrote:
On 12/05/2013 07:43 PM, Jan Lieskovsky wrote:
From: "Ralf Corsepius"
Would you mind to explain why you guys are putting such an
emphasize on
On 12/06/2013 11:30 AM, Adam Williamson wrote:
On Fri, 2013-12-06 at 10:37 +0100, Ralf Corsepius wrote:
On 12/05/2013 07:43 PM, Jan Lieskovsky wrote:
From: "Ralf Corsepius"
Would you mind to explain why you guys are putting such an emphasize on
-Wformat-security?
Some possible ways how to
On 12/06/13 at 11:57am, Reindl Harald wrote:
> but what is the plan if this does not work out for a unknown number
> of packages because upstream is not willing or able to "fix it" or
> only in a later release giving that the package is not buildable
> at all
Contingency mechanism: Revert changes
Am 06.12.2013 11:30, schrieb Adam Williamson:
> On Fri, 2013-12-06 at 10:37 +0100, Ralf Corsepius wrote:
>> On 12/05/2013 07:43 PM, Jan Lieskovsky wrote:
>>
From: "Ralf Corsepius"
>>
Would you mind to explain why you guys are putting such an emphasize on
-Wformat-security?
>>>
>>> S
On Fri, 2013-12-06 at 10:37 +0100, Ralf Corsepius wrote:
> On 12/05/2013 07:43 PM, Jan Lieskovsky wrote:
>
> >> From: "Ralf Corsepius"
>
> >> Would you mind to explain why you guys are putting such an emphasize on
> >> -Wformat-security?
> >
> > Some possible ways how to look at it:
> > * because
Am 06.12.2013 10:37, schrieb Ralf Corsepius:
>>> IMO, -Wformat-security is almost negibile in comparison to these and you
>>> are making way too much noise about it than it deserves.
>>
>> http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=format+string [*]
>
> Yeah, a vulnerability - So what?
>
>
On 12/05/2013 07:43 PM, Jan Lieskovsky wrote:
From: "Ralf Corsepius"
Would you mind to explain why you guys are putting such an emphasize on
-Wformat-security?
Some possible ways how to look at it:
* because when all reported packages are patched, it would remove one
whole class of secur
On 12/05/2013 03:25 AM, mrnuke wrote:
On 12/04/2013 12:10 PM, Brendan Jones wrote:
This is just a pain. Can someone explain to me why this is good?
Good or not, this is not the right question to ask.
* Is this necessarry, and are the benefits worth the pains? *
This change is Sofa King st
On Fri, 06 Dec, 2013 at 01:21:20 GMT, Kevin Kofler wrote:
> a printf wrapper for logging which adds a timestamp in front of the
> format string.
Use the printf attribute on the function to fix this. See stalonetray's
patch[1]. It can't be done portably with a macro (you need ##
__VA_ARGS__ for tha
On 12/05/2013 11:38 AM, Michael scherer wrote:
> On Wed, Dec 04, 2013 at 08:25:54PM -0600, mrnuke wrote:
>>
>> This change is Sofa King stupid. Why couldn't we have just enabled the
>> warning without turning it into an error, THEN let packagers work with
>> upstream in fixing those warnings? Regul
Jan Lieskovsky wrote:
> I think the point of turning the warning into explicit error is to
> intentionally make the package / source build failing to indicate there's
> an error present somewhere in the code and that it should be fixed.
But in many cases there actually ISN'T any error to begin wit
On 12/05/2013 09:41 AM, Florian Weimer wrote:
> For the current stage (filing bugs for known failures), it does not make
> much of a difference how the data is obtained about future build
> failures. Filing bugs seems reasonable for tracking purposes.
>
The FESCO ticket is about enabling -Werror=
Michael scherer wrote:
> Let's rather ask the contrary, why is this so much a issue to communicate
> with upstream to fix things, and add patches ?
The vast majority of those warnings are actually false positives, not actual
security issues. Putting my upstream hat on, if asked to "fix" such a fa
Let me reproduce here for a wider audience my comments I have just posted in
the FESCo ticket:
IMHO, turning this warning into an error is a horribly flawed idea. It just
has way too many false positives. For example, here's the snippet it
complains about in Qt 3:
QString line;
line.fi
On Thu, Dec 05, 2013 at 07:11:19PM +0100, Ralf Corsepius wrote:
> Sure, there are some serious cases, but ... there are many more
> further spread issues in C/C++-sources which people have been
> ignoring ever since Fedora and RH Linux distros exist.
>
> IMO, -Wformat-security is almost negibile
On Wed, Dec 04, 2013 at 11:56:23PM +0100, Brendan Jones wrote:
> Patching is not a problem. Unnecessary is the question. Explain to
> me (not you in particular Rahul) how these printf's can possibly be
> exploited?
To expand on my earlier mail: the printf usage in hydrogen is definitely
horribly w
- Original Message -
> On Wed, Dec 04, 2013 at 05:11:16PM -0600, Ian Pilcher wrote:
> > On 12/04/2013 04:56 PM, Brendan Jones wrote:
> > > Patching is not a problem. Unnecessary is the question. Explain to me
> > > (not you in particular Rahul) how these printf's can possibly be
> > > explo
- Original Message -
> From: "Ralf Corsepius"
> To: devel@lists.fedoraproject.org
> Sent: Thursday, December 5, 2013 7:11:19 PM
> Subject: Re: FTBFS if "-Werror=format-security" flag is used
>
> On 12/05/2013 06:38 PM, Michael scherer wrote:
> &
On Wed, Dec 04, 2013 at 11:56:23PM +0100, Brendan Jones wrote:
> Patching is not a problem. Unnecessary is the question. Explain to
> me (not you in particular Rahul) how these printf's can possibly be
> exploited?
Uhm, I just took a look at the hydrogen source. The problem with it is
that it's no
On 12/05/2013 06:38 PM, Michael scherer wrote:
On Wed, Dec 04, 2013 at 08:25:54PM -0600, mrnuke wrote:
On 12/04/2013 12:10 PM, Brendan Jones wrote:
This is just a pain. Can someone explain to me why this is good?
Good or not, this is not the right question to ask.
* Is this necessarry, an
On Wed, Dec 04, 2013 at 10:09:43PM +0100, devzero2000 wrote:
> Interesting, for me almost, that many refs are from debian/ubuntu world.
Well, that's the convenience of being late to the party. The majority of
the work was already done by other distros and we can build upon that.
In other cases Fe
On Wed, Dec 04, 2013 at 08:25:54PM -0600, mrnuke wrote:
> On 12/04/2013 12:10 PM, Brendan Jones wrote:
> >
> > This is just a pain. Can someone explain to me why this is good?
> >
> Good or not, this is not the right question to ask.
>
> * Is this necessarry, and are the benefits worth the pain
On Wed, Dec 4, 2013 at 7:29 PM, Daniel P. Berrange wrote:
> On Wed, Dec 04, 2013 at 07:10:39PM +0100, Brendan Jones wrote:
>>
>> This is just a pain. Can someone explain to me why this is good?
>
> If you read the bug description you'll see the link which
> answers your question.
>
> https://fed
On 12/05/2013 03:25 AM, mrnuke wrote:
On 12/04/2013 12:10 PM, Brendan Jones wrote:
This is just a pain. Can someone explain to me why this is good?
Good or not, this is not the right question to ask.
* Is this necessarry, and are the benefits worth the pains? *
This change is Sofa King st
- Original Message -
> From: "mrnuke"
> To: devel@lists.fedoraproject.org
> Sent: Thursday, December 5, 2013 3:37:14 PM
> Subject: Re: FTBFS if "-Werror=format-security" flag is used
>
> On 12/05/2013 07:38 AM, Ralf Corsepius wrote:
> >
On 12/05/2013 07:38 AM, Ralf Corsepius wrote:
> As I see it, GCC's -Wformat-security is too unreliable to be used in
> production. It certainly diagnoses valid security leaks in some cases,
> but all it does in other cases is to enforce stylishness to work outs
> GCC's limitations. I.e. in these ca
On 12/05/2013 02:15 PM, Florian Weimer wrote:
On 12/05/2013 11:00 AM, Ralf Corsepius wrote:
On 12/05/2013 10:26 AM, Björn Persson wrote:
Brendan Jones wrote:
Patching is not a problem. Unnecessary is the question. Explain to me
(not you in particular Rahul) how these printf's can possibly be
e
On 12/05/2013 11:00 AM, Ralf Corsepius wrote:
On 12/05/2013 10:26 AM, Björn Persson wrote:
Brendan Jones wrote:
Patching is not a problem. Unnecessary is the question. Explain to me
(not you in particular Rahul) how these printf's can possibly be
exploited?
I believe to be able to prove GCC i
On 12/05/2013 10:26 AM, Björn Persson wrote:
Brendan Jones wrote:
Patching is not a problem. Unnecessary is the question. Explain to me
(not you in particular Rahul) how these printf's can possibly be
exploited?
I believe to be able to prove GCC is producing bogus warnings:
Cf. https://bugzil
Brendan Jones wrote:
>Patching is not a problem. Unnecessary is the question. Explain to me
>(not you in particular Rahul) how these printf's can possibly be
>exploited?
Even if you could prove that a % can never occur in any of these
strings, so that the error can't even cause a crash in any of
On 12/04/2013 12:10 PM, Brendan Jones wrote:
>
> This is just a pain. Can someone explain to me why this is good?
>
Good or not, this is not the right question to ask.
* Is this necessarry, and are the benefits worth the pains? *
This change is Sofa King stupid. Why couldn't we have just enabl
On Wed, Dec 4, 2013 at 3:54 PM, Brendan Jones
wrote:
> On 12/05/2013 12:28 AM, Miloslav Trmač wrote:
>>
>> On Thu, Dec 5, 2013 at 12:11 AM, Brendan Jones
>> wrote:
>>>
>>> On 12/05/2013 12:11 AM, Ian Pilcher wrote:
On 12/04/2013 04:56 PM, Brendan Jones wrote:
>
>
> Patc
On 12/05/2013 12:28 AM, Miloslav Trmač wrote:
On Thu, Dec 5, 2013 at 12:11 AM, Brendan Jones
wrote:
On 12/05/2013 12:11 AM, Ian Pilcher wrote:
On 12/04/2013 04:56 PM, Brendan Jones wrote:
Patching is not a problem. Unnecessary is the question. Explain to me
(not you in particular Rahul) how
On Thu, Dec 5, 2013 at 12:11 AM, Brendan Jones
wrote:
> On 12/05/2013 12:11 AM, Ian Pilcher wrote:
>>
>> On 12/04/2013 04:56 PM, Brendan Jones wrote:
>>>
>>> Patching is not a problem. Unnecessary is the question. Explain to me
>>> (not you in particular Rahul) how these printf's can possibly be
>
On 12/05/2013 12:11 AM, Ian Pilcher wrote:
On 12/04/2013 04:56 PM, Brendan Jones wrote:
Patching is not a problem. Unnecessary is the question. Explain to me
(not you in particular Rahul) how these printf's can possibly be exploited?
char *output;
output = get_user_input(...);
printf
On Wed, Dec 04, 2013 at 05:11:16PM -0600, Ian Pilcher wrote:
> On 12/04/2013 04:56 PM, Brendan Jones wrote:
> > Patching is not a problem. Unnecessary is the question. Explain to me
> > (not you in particular Rahul) how these printf's can possibly be exploited?
>
> char *output;
>
> output =
On 12/04/2013 04:56 PM, Brendan Jones wrote:
> Patching is not a problem. Unnecessary is the question. Explain to me
> (not you in particular Rahul) how these printf's can possibly be exploited?
char *output;
output = get_user_input(...);
printf(output);
What happens when the user enters %
On Wed, Dec 04, 2013 at 11:56:23PM +0100, Brendan Jones wrote:
> Patching is not a problem. Unnecessary is the question. Explain to
> me (not you in particular Rahul) how these printf's can possibly be
> exploited?
Google for sudo format string exploit
Yours Tony
pgpit7eFTE85S.pgp
Description:
On 12/04/2013 09:39 PM, Rahul Sundaram wrote:
Hi
On Wed, Dec 4, 2013 at 3:05 PM, Brendan Jones wrote:
Overkill if you ask me,
It might be appear to be one till it ends up avoiding or mitigating a
security issue. It is just a bunch of trivial changes and I am sure you
can ask for help f
Hi
On Wed, Dec 4, 2013 at 3:05 PM, Brendan Jones wrote:
>
> Overkill if you ask me,
>
It might be appear to be one till it ends up avoiding or mitigating a
security issue. It is just a bunch of trivial changes and I am sure you
can ask for help for patches if needed.
Rahul
--
devel mailing l
On 12/04/2013 07:59 PM, Rahul Sundaram wrote:
Hi
On Wed, Dec 4, 2013 at 1:45 PM, Brendan Jones wrote:
I'm sorry, but I can't see why any of my packages (10+) are at risk
This is just a best practice to mitigate any risks that might exist just
like any of the other security improvements
Hi
On Wed, Dec 4, 2013 at 1:45 PM, Brendan Jones wrote:
>
> I'm sorry, but I can't see why any of my packages (10+) are at risk
>
This is just a best practice to mitigate any risks that might exist just
like any of the other security improvements we make from time to time.
Even if you don't see
On 12/04/2013 07:29 PM, Daniel P. Berrange wrote:
On Wed, Dec 04, 2013 at 07:10:39PM +0100, Brendan Jones wrote:
This is just a pain. Can someone explain to me why this is good?
If you read the bug description you'll see the link which
answers your question.
https://fedoraproject.org/wiki
On Wed, Dec 04, 2013 at 07:10:39PM +0100, Brendan Jones wrote:
>
> This is just a pain. Can someone explain to me why this is good?
If you read the bug description you'll see the link which
answers your question.
https://fedoraproject.org/wiki/Format-Security-FAQ
Daniel
--
|: http://berrange
95 matches
Mail list logo
