On Jun 18, 3:41 am, Kaspar Brand <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > If I got that part right, then when I loaded the x509.cacert into my
> > XUL application and tried to use signtool to sign an archieve, it was
> > failing because I was trying to sign with a public key.
>
> O
FYI.
--- Begin Message ---
Please forward to all appropriate contacts and lists. They're all free.
Thanks.
Arshad Noor
StrongAuth, Inc.
Register now for the OASIS Series of SECURITY Standards Webinars!
It's everything you always wanted to know about security standards--from the
people who cre
Benjamin Smedberg wrote:
> Gervase Markham wrote:
>
>> This seems like the right solution to me. In fact, I had assumed it was
>> already the case, and that we were trying to solve the other half of the
>> problem.
>
> We already support hashes specified by the upate.rdf for the XPI, and AMO
> us
On 6/19/07, Anders Rundgren <[EMAIL PROTECTED]> wrote:
> Wan-Teh,
> I got the impression from Nelson's reply that JSS would give me the desired
> functionality (giving me all FF certificate stores as one). I will look on
> crypto.signText because it should be faced with the similar issue, right?
Gervase Markham schrieb:
> Nils Maier wrote:
> [...]
>> PS: the Link-Fingerprints "standard" says:
>>> Clients are encouraged not to implement any hash algorithms other
>>> than MD5 and SHA-256, until and unless SHA-256 is found to have flaws.
>> MD5 is broken, you can find collisions in just hours
Gervase Markham wrote:
> This seems like the right solution to me. In fact, I had assumed it was
> already the case, and that we were trying to solve the other half of the
> problem.
We already support hashes specified by the upate.rdf for the XPI, and AMO
uses this to serve the XPIs over http. H
Nils Maier wrote:
> Link-Fingerprints cannot solve the problem of update.rdf-over-HTTP as
> update.rdf is likely to update often and you cannot compute hash(es) for
> it in advance.
I didn't suggest that it could.
> If you're proposing that all extensions or at least their update.rdf
> must be se
Dave Townsend wrote:
> Gervase Markham wrote:
>> Dave Townsend wrote:
>>> What I want is to be able to be able to establish some trust that the
>>> update file retrieved is correct, and has not been tampered with,
>>> intercepted and is as it was originally written by the add-on author.
>>
>> Lin
Wan-Teh,
I got the impression from Nelson's reply that JSS would give me the desired
functionality (giving me all FF certificate stores as one). I will look on
crypto.signText because it should be faced with the similar issue, right?
Anders
- Original Message -
From: "Wan-Teh Chang" <[EM
9 matches
Mail list logo
