Daniel (or do you like Dan more?),

As far as the GPG key, perhaps you could distribute it on bittorrent or
some other p2p system if you're worried about maintaining it or are worried
that the governments might interfere. Although, I agree that GPG
communication is kind of a burden. The clients for it aren't very friendly
really.

Only slightly related to the whole set of questions,
Will

On Mon, Sep 29, 2014 at 12:05 AM, Daniel Stenberg <daniel_at_haxx.se> wrote:

> On Mon, 29 Sep 2014, bancfc_at_openmailbox.org wrote:
>
> Thanks for your interest in helping us improve!
>
> 1. Can you please make curl take advantage of seccomp? Its a kernel
>> syscall filter that greatly restricts what a misbehaving program can do if
>> its remotely exploited.
>>
>
> Can you clarify what that would require from us?
>
> 2. If your time permits, maybe create and maintain an apparmor profile
>> for curl in Debian. Profiles for SELinux are welcome as well but I'm
>> mentioning Apparmor because its predominantly used in Debian (our base).
>>
>
> Sorry, but I don't think that's a task for the curl project. We produce a
> product that works on all operating systems and all distributions. For
> distro-specific adaptions you're better off discussing with those
> distributions.
>
> I mean, I wouldn't block anyone from providing such a thing and submitting
> it to the project but I will personally not put it on my shortlist, and if
> we would add it to the project I fear it'd grow outdated rather soon... It
> is much better to provide Debian things to Debian itself!
>
> 3. This security tip is not related to curl itself, but in a post-Snowden
>> age it would make sense if you provide a GPG fingerprint for the security
>> bug email account so researchers could contact you about bugs
>> confidentially without a government sniffing this sensitive information
>> before a fix is available.
>>
>
> Yeah, I agree that this would be useful. I think I've held this off so far
> because it is a real maintanence burden and complexity to add and handle
> that I haven't found a will to tackle.
>
> We only ever "hold on" to security vulnerability information for as long
> as we can release a fixed version, which we do at least every 8th week -
> and we can do it faster if we need to. This way, even if an evil snooper
> would figure out a security problem by litesting in to the communication of
> one of the curl-security list members it would only be secret for a rather
> short period of time.
>
> 4. Compile-time hardening is probably only relevant to Debian package
>> maintainers, but I'll mention it here if thats ok. The checksec script
>> reports that only partial RELRO is supported and PIE hardening isn't
>> enabled at all. I am discussing this with the maintainer. If needed, can
>> you please consider making the necessary changes to cur to support all
>> hardening flags?
>>
>
> AFAIK you can already quite easily provide your own set of compile-time
> options for both compilers and linkers etc so I don't think we need to
> change anything to support this.
>
> --
>
> / daniel.haxx.se
> -------------------------------------------------------------------
> List admin: http://cool.haxx.se/list/listinfo/curl-library
> Etiquette: http://curl.haxx.se/mail/etiquette.html

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2014-09-29