[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[Popcon-developers] Compressed/encrypted popcon report.

[Bill Allombert]
> I have looked at compressing/encrypting popcon reports.
> The problem I have with MIME header is that they do not allow me
> to armor the subscription unless I use a Content-Type of
> x-popcon. Eventually we could register an application able to
> read x-popcon message.

I do not understand the problem.  Using a special content-type is OK
with me, but I do not understand why you don't like it.  Please

I believe there is some extra headers to use to document that the
content type is compressed as well.  I do not remember the details,
but know that a similar feature is used by webservers, specifying
content-type text/html, and adding some flags specifying that the html
code is compressed using gzip.

> The encryption idea is to ship a public key in the popcon package
> and use it to encrypt the report. The popcon server will have the 
> secret key and decrypt the reports.
> The other issue is that I wonder how may time need gluck to
> decrypt 800 reports of 3MB each.

Not sure about this one.  We could make it a hidden config option, and
gain some experience with it before we make it the default.

I suspect encrypting the info will make some people stop using popcon,
as they can not easily check which info is sent to the server.  And I
am not sure why encryption would be good.  People unwilling to share
their package list with all people capable of looking at it in
transit, would probably be unwilling to share it with us as well.

Reply to: