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 sources and
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'
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:
qWarning()
On Tue, Dec 10, 2013 at 3:00 AM, Kevin Kofler kevin.kof...@chello.at 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
drago01 wrote:
On Tue, Dec 10, 2013 at 3:00 AM, Kevin Kofler kevin.kof...@chello.at
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,
On Tue, Dec 10, 2013 at 3:50 PM, Kevin Kofler kevin.kof...@chello.at wrote:
drago01 wrote:
On Tue, Dec 10, 2013 at 3:00 AM, Kevin Kofler kevin.kof...@chello.at
wrote:
[...] and removes functionality
No it does not.
Yes, it does, see my example:
| a printf wrapper for logging which adds a
On 12/10/2013 04:35 PM, Miloslav Trmač wrote:
On Tue, Dec 10, 2013 at 3:50 PM, Kevin Kofler kevin.kof...@chello.at wrote:
drago01 wrote:
On Tue, Dec 10, 2013 at 3:00 AM, Kevin Kofler kevin.kof...@chello.at
-Werror=format-security removes the functionality of building format strings
at
Once upon a time, Ralf Corsepius rc040...@freenet.de 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
Once upon a time, Chris Adams li...@cmadams.net 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
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 this as
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 this as
1. There are legitimate use-cases where GCC's assumption does not hold, .e.g.:
#include stdio.h
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: warning:
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.
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 doesn't
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, %s
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
perfectly
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
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 repetitive, but the
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.
My apologies for being
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
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 insecure
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
compatibility
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
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't
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
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?
I'd guess the
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 when all reported
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?
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 to
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/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/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,
Can you
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
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
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
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
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 [*]
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.
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
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 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 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
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
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
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 timestamp in
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 able to
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:
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 metaphor.
On Fri, Dec 6, 2013 at 4:50 PM, Ralf Corsepius rc040...@freenet.de 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
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
In the
On Fri, Dec 6, 2013 at 8:02 PM, Kevin Kofler kevin.kof...@chello.at 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
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 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, 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 vast majority
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 let
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
scripting
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 vast majority
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.
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/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.
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
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
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 case
- Original Message -
From: mrnuke mr.nuke...@gmail.com
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:
As I see it, GCC's -Wformat-security is too
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
On Wed, Dec 4, 2013 at 7:29 PM, Daniel P. Berrange berra...@redhat.com 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.
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 pains? *
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
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,
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 not
- 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
exploited?
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
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 in
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;
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 false
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
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 with!
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? Regulate, not
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
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
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
--
|:
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.
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: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 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
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
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 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 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/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(...);
On Thu, Dec 5, 2013 at 12:11 AM, Brendan Jones
brendan.jones...@gmail.com 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
On 12/05/2013 12:28 AM, Miloslav Trmač wrote:
On Thu, Dec 5, 2013 at 12:11 AM, Brendan Jones
brendan.jones...@gmail.com 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
On Wed, Dec 4, 2013 at 3:54 PM, Brendan Jones
brendan.jones...@gmail.com wrote:
On 12/05/2013 12:28 AM, Miloslav Trmač wrote:
On Thu, Dec 5, 2013 at 12:11 AM, Brendan Jones
brendan.jones...@gmail.com wrote:
On 12/05/2013 12:11 AM, Ian Pilcher wrote:
On 12/04/2013 04:56 PM, Brendan Jones
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 enabled
94 matches
Mail list logo
