Wade Richards <[EMAIL PROTECTED]> wrote on 08/09/2003 (10:10) :
> The safest approach is always to ensure that the answer to the first
> question is "no", so you don't need to worry about the second one.
And the only approach! Never take calculated risks in these matter when
one is dealing with C/
Wade Richards <[EMAIL PROTECTED]> wrote on 08/09/2003 (10:10) :
> The safest approach is always to ensure that the answer to the first
> question is "no", so you don't need to worry about the second one.
And the only approach! Never take calculated risks in these matter when
one is dealing with C/
Matt Zimmerman wrote:
> Only root has control over apt's packages lists and the dpkg status
> file, so
> I wouldn't be too concerned about this from a security standpoint. It's
> still sloppy, and I would think twice before stepping forward to take
> over maintenance of such a program, rather tha
Matt Zimmerman wrote:
> Only root has control over apt's packages lists and the dpkg status
> file, so
> I wouldn't be too concerned about this from a security standpoint. It's
> still sloppy, and I would think twice before stepping forward to take
> over maintenance of such a program, rather tha
On Fri, Sep 05, 2003 at 11:07:12PM +0100, Dale Amon wrote:
> On Fri, Sep 05, 2003 at 08:19:46PM +0200, Frank Lichtenheld wrote:
> > The question that remains is: Does this require a security update for
> > the woody version of the package? Or should I just try to get this
> > fixed in the next rel
On Fri, Sep 05, 2003 at 08:19:46PM +0200, Frank Lichtenheld wrote:
> The question that remains is: Does this require a security update for
> the woody version of the package? Or should I just try to get this
> fixed in the next release (of the package)?
I'd say yes. It's one for which someone migh
On Fri, Sep 05, 2003 at 11:07:12PM +0100, Dale Amon wrote:
> On Fri, Sep 05, 2003 at 08:19:46PM +0200, Frank Lichtenheld wrote:
> > The question that remains is: Does this require a security update for
> > the woody version of the package? Or should I just try to get this
> > fixed in the next rel
On Fri, Sep 05, 2003 at 12:37:27PM -0700, Wade Richards wrote:
The safest approach is always to ensure that the answer to the first
question is "no", so you don't need to worry about the second one.
More to the point, if someone can get you to install arbitrary untrusted
packages you have bigge
On Fri, Sep 05, 2003 at 08:19:46PM +0200, Frank Lichtenheld wrote:
> The question that remains is: Does this require a security update for
> the woody version of the package? Or should I just try to get this
> fixed in the next release (of the package)?
I'd say yes. It's one for which someone migh
On Fri, Sep 05, 2003 at 04:47:30PM +0200, Frank Lichtenheld wrote:
> several code pieces like
>
> char path[256];
> sprintf( path, "some string/%s", packagename);
>
> Is such code (away from the fact that it can easily lead to segfaults) a
> security problem?
Yep, it's a potential security probl
On Fri, Sep 05, 2003 at 12:37:27PM -0700, Wade Richards wrote:
The safest approach is always to ensure that the answer to the first
question is "no", so you don't need to worry about the second one.
More to the point, if someone can get you to install arbitrary untrusted
packages you have bigger pr
On Fri, Sep 05, 2003 at 04:26:55PM +0100, Thomas Horsten wrote:
> Hi Frank,
>
> On Fri, 5 Sep 2003, Frank Lichtenheld wrote:
>
> > char path[256];
> > sprintf( path, "some string/%s", packagename);
> >
> > There are no further checks as I can see. I'm not very experienced in C
> > programming and
On Fri, Sep 05, 2003 at 04:47:30PM +0200, Frank Lichtenheld wrote:
> several code pieces like
>
> char path[256];
> sprintf( path, "some string/%s", packagename);
>
> Is such code (away from the fact that it can easily lead to segfaults) a
> security problem?
Yep, it's a potential security probl
On Fri, Sep 05, 2003 at 04:26:55PM +0100, Thomas Horsten wrote:
> Hi Frank,
>
> On Fri, 5 Sep 2003, Frank Lichtenheld wrote:
>
> > char path[256];
> > sprintf( path, "some string/%s", packagename);
> >
> > There are no further checks as I can see. I'm not very experienced in C
> > programming and
Hi Frank,
On Fri, 5 Sep 2003, Frank Lichtenheld wrote:
> char path[256];
> sprintf( path, "some string/%s", packagename);
>
> There are no further checks as I can see. I'm not very experienced in C
> programming and don't know much about the details of exploiting buffer
> overflows or the like...
On Fri, Sep 05, 2003 at 04:47:30PM +0200, Frank Lichtenheld wrote:
> I recently adopted the magpie package (It reads in Packages files and
> produces HTML output)
>
> It was un/undermaintained a long time and has no separate upstream.
> While looking in the code to fix some outstanding bugs I fou
On Fri, Sep 05, 2003 at 04:47:30PM +0200, Frank Lichtenheld wrote:
> Hi.
Hello :)
> It was un/undermaintained a long time and has no separate upstream.
> While looking in the code to fix some outstanding bugs I found
> several code pieces like
>
> char path[256];
> sprintf( path, "some string/%s"
/ 2003-09-05 16:47:30 +0200
\ Frank Lichtenheld:
> Hi.
>
> I recently adopted the magpie package (It reads in Packages files and
> produces HTML output)
>
> It was un/undermaintained a long time and has no separate upstream.
> While looking in the code to fix some outstanding bugs I found
> sever
Frank Lichtenheld <[EMAIL PROTECTED]> writes:
> char path[256];
> sprintf( path, "some string/%s", packagename);
> Is such code (away from the fact that it can easily lead to segfaults) a
> security problem?
In general, yes.
Hi.
I recently adopted the magpie package (It reads in Packages files and
produces HTML output)
It was un/undermaintained a long time and has no separate upstream.
While looking in the code to fix some outstanding bugs I found
several code pieces like
char path[256];
sprintf( path, "some string/
Hi Frank,
On Fri, 5 Sep 2003, Frank Lichtenheld wrote:
> char path[256];
> sprintf( path, "some string/%s", packagename);
>
> There are no further checks as I can see. I'm not very experienced in C
> programming and don't know much about the details of exploiting buffer
> overflows or the like...
On Fri, Sep 05, 2003 at 04:47:30PM +0200, Frank Lichtenheld wrote:
> I recently adopted the magpie package (It reads in Packages files and
> produces HTML output)
>
> It was un/undermaintained a long time and has no separate upstream.
> While looking in the code to fix some outstanding bugs I fou
On Fri, Sep 05, 2003 at 04:47:30PM +0200, Frank Lichtenheld wrote:
> Hi.
Hello :)
> It was un/undermaintained a long time and has no separate upstream.
> While looking in the code to fix some outstanding bugs I found
> several code pieces like
>
> char path[256];
> sprintf( path, "some string/%s"
/ 2003-09-05 16:47:30 +0200
\ Frank Lichtenheld:
> Hi.
>
> I recently adopted the magpie package (It reads in Packages files and
> produces HTML output)
>
> It was un/undermaintained a long time and has no separate upstream.
> While looking in the code to fix some outstanding bugs I found
> sever
Frank Lichtenheld <[EMAIL PROTECTED]> writes:
> char path[256];
> sprintf( path, "some string/%s", packagename);
> Is such code (away from the fact that it can easily lead to segfaults) a
> security problem?
In general, yes.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "uns
Hi.
I recently adopted the magpie package (It reads in Packages files and
produces HTML output)
It was un/undermaintained a long time and has no separate upstream.
While looking in the code to fix some outstanding bugs I found
several code pieces like
char path[256];
sprintf( path, "some string/
26 matches
Mail list logo
