Joerg Schilling schrieb am 29.04.2013 18:36:
> Daniel Pielmeier wrote:
>
>> 2013/4/29 Joerg Schilling
>
>>> Do you like people to be able to open security holes?
>>
>> Adding an option to enable/disable linkage to libcap does not hurt anybody
>> it just eases maintaining the package. You can en
On 30/04/13 11:50, Joerg Schilling wrote:
Nikos Chantziaras wrote:
Would you call someone who shoots himself into the foot "smart"?
Recent Linux kernels support fcaps in the filesystems and "somebody" evil, who
knows what he does may even set up fcaps on executable files when the related
supp
Nikos Chantziaras wrote:
> > Would you call someone who shoots himself into the foot "smart"?
> >
> > Recent Linux kernels support fcaps in the filesystems and "somebody" evil,
> > who
> > knows what he does may even set up fcaps on executable files when the
> > related
> > support-software is
On 29/04/13 17:22, Joerg Schilling wrote:
Nikos Chantziaras wrote:
You don't know what my intentions are. I might be doing testing,
debugging, who knows what. It's the "trying to be smarter than the
user" thing. The defaults of course would be to built the software in a
sane, secure way. On
Daniel Pielmeier wrote:
> 2013/4/29 Joerg Schilling
> > Do you like people to be able to open security holes?
>
> Adding an option to enable/disable linkage to libcap does not hurt anybody
> it just eases maintaining the package. You can enable it by default if you
> wish.
>
> As long as it is
2013/4/29 Joerg Schilling
> Nikos Chantziaras wrote:
>
> > > This may be an option for things that really are optional.
> > >
> > > Libcap however is not something optional but needed to support a basic
> security
> > > feature.
> >
> > I thought it is optional, since it was mentioned that cdrto
Nikos Chantziaras wrote:
> > This may be an option for things that really are optional.
> >
> > Libcap however is not something optional but needed to support a basic
> > security
> > feature.
>
> I thought it is optional, since it was mentioned that cdrtools can be
> built and ran without it?
On 29/04/13 16:09, Joerg Schilling wrote:
Nikos Chantziaras wrote:
But please first explain what "option" you are talking about.
An option to forcibly enable and disable support. If enabled, the build
system assumes the library is there. If disabled, it assumes the
library is not there (ev
Nikos Chantziaras wrote:
> > But please first explain what "option" you are talking about.
>
> An option to forcibly enable and disable support. If enabled, the build
> system assumes the library is there. If disabled, it assumes the
> library is not there (even if it is). If not given at al
On 29/04/13 14:33, Joerg Schilling wrote:
Daniel Pielmeier wrote:
with the situation I have here. In my opinion it is a good idea to add
such an option. If you think otherwise I am fine with it and I have to
use other means to make cdrtools compatible with Gentoo.
Cdrtools is compatible with
Daniel Pielmeier wrote:
> Nikos Chantziaras schrieb am 27.04.2013 08:07:
> > On 26/04/13 23:20, Joerg Schilling wrote:
> >>
> >> The only problem I see is that you are able to remove important
> >> software on a
> >> Linux installation while the kernel still supports the feature by
> >> default.
Nikos Chantziaras schrieb am 27.04.2013 08:07:
> On 26/04/13 23:20, Joerg Schilling wrote:
>>
>> The only problem I see is that you are able to remove important
>> software on a
>> Linux installation while the kernel still supports the feature by
>> default.
>
> You are not able to remove it if so
On 26/04/13 23:20, Joerg Schilling wrote:
The only problem I see is that you are able to remove important software on a
Linux installation while the kernel still supports the feature by default.
You are not able to remove it if something actually uses it. If you
remove the automagic dependen
13 matches
Mail list logo
