"Largest hacker conference in the free world".
Running at the moment.
All talks made available on video.
Many talks in English. German talks should be translated to English, in
the order of interest.
"Hacking" here means "Having fun using devices in creative/new ways" and
anything security-relate
On 26.01.2011 00:02, Honza Bambas wrote:
Ben, proxy info (the last argument) could make a trick for you. Fill
proxy info with host:port of the server (as it actually stands as a
proxy between the two clients). Let host name passed to
createTransport() be the name of the [cert].
Thanks for
Just to be clear, to avoid confusion: this was a pure programming
question, not a server admin or PKI setup question. I write a client for
an existing standard protocol, and it's supposed to work with the
existing servers, over which I have no control.
Ben
--
dev-tech-crypto mailing lis
s connection.
Remember, as I said initially, that the idea of SSL is that the cert is
for the service that the user intended to go to, not where you end up
technically via possibly insecure lookups.
Ben
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
01.2011 16:09, Ben Bucksch wrote:
* check what the exact error is, and handle "hostname mismatches
cert" error only (OPEN - that's why I tried to get the
nsITransportSecurityInfo.errorMessage above, so I don't know how
to achieve that)
* override that err
On 24.01.2011 15:10, Ben Bucksch wrote:
In my nsIBadCertListener2::notifyCertProblem(), I try to
getInterface(nsITransportSecurityInfo) from socketInfo, because
nsNSSIOLayer.cpp::nsNSSBadCerthandler() lines 3348 and 3577 suggest
that it should be a nsNSSSocketInfo object, which implements
On 24.01.2011 12:38, Ben Bucksch wrote:
Worst comes to worst, I can always override the cert error, and do the
check myself, but that's going to get quite ugly.
I have to say the PSM IDL interfaces are coming right out of the black
hole. I implement nsIBadCertListener2 and nsISSLErrorLis
ed to customers in 1-2 months,
therefore I need to run on FF3.6 and FF4.0.
Any ideas for workarounds towards the API?
Worst comes to worst, I can always override the cert error, and do the
check myself, but that's going to get quite ugly.
Ben
--
dev-tech-crypto mailing list
dev-tech-cryp
cessarily what we end up with.
Most libs, e.g. java and Python, even require the app author to
explicitly set this. So, I assume that possibility is somewhere, I just
didn't find the API.
Can somebody help?
Ben
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
In article <20100407160150.2b5d0637.r...@reedloden.com> you wrote:
> On Wed, 7 Apr 2010 16:18:41 -0400
> Ben Boeckel wrote:
>
>> While going through fixing memory leaks in CHASM[1], I fixed some leaks
>> within NSPR and NSS.
>
> Ben, thanks for the work h
a machine with a
proper fqdn and rerun the tests (with and without my patches). Thanks.
--Ben
[1]http://chasmd.org
Index: nsprpub/pr/include/prerr.h
===
RCS file: /cvsroot/mozilla/nsprpub/pr/include/prerr.h,v
retrieving revision 3.
thing about how to hash with it in the docs). Any hints? Thanks in
advance.
- --Ben
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
iQIbBAEBCAAGBQJLey/pAAoJEKaxavVX4C1XgycP9iOLylnAAClcAJCr8n8oaOm9
IDlM2O/AwQNuafnW4nHJvFOURv4aqrcRh3QNSK8DUUl6viWT70pMCQ5xIATgKptL
QtqW9L9PjjLPdyb5
On 03.05.2009 09:06, Ian G wrote:
(5) possibly as consequence of all the above, it can be claimed that
it is an empty threat, and no more than a security/marketing tool for
PKI people.
Consequently, we need to either:
* Make that threat not empty
* Create other ways to make CAs behave when the
On 13.02.2009 20:37, kathleen95...@yahoo.com wrote:
Certigna’s CPS contains sensitive information that cannot be posted
publicly at this time. As such, the following possible solutions are
recommended:
1) Publish a version of the CPS with the confidential material
redacted.
Yeah, that's fin
On 13.02.2009 16:56, Ian G wrote:
But it isn't me that sets the criteria, it is in this case ETSI, and
the *policy* clearly says that ETSI is acceptable, and apparently ETSI
say non-publication is ok.
FWIW, this is irrelevant. *We* require the ETSI. We can also require
additional requirements
rrants to relying parties.
Even more so must the "recommended practices" be that it's public.
I agree with Eddy's revert, and disagree that you just unilaterally
change the recommended practices to the worse, be it a wiki or not.
Ben
--
dev-tech-crypto mailing list
dev-tech-crypt
On 13.02.2009 16:15, Ben Bucksch wrote:
Ian, I also disagree with your change. CPS IMHO must be public,
period. It's important for "Relying parties". The CPS is the only
thing that shows what the CA actually does and warrants to relying
parties.
Even more so must the "r
On 10.02.2009 02:23, Nelson B Bolyard wrote:
I'd post this in the policy working group, if that was operational ... :(
In
our esteemed Kathleen Wilson wrote:
According to https://wiki.mozilla.org/CA:How_to_apply
“If there are no open issues or action items after the first
discussion perio
On 09.02.2009 17:45, Ian G wrote:
I've posted something ... hopefully non-contraversial ...: a
suggestion on the list charter.
That was a good one.
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
On 27.01.2009 05:20, Gervase Markham wrote:
https://bugzilla.mozilla.org/show_bug.cgi?id=475473
filed to create mozilla.dev.security.policy. And please let's not have a
bikeshed discussion about the name.
Sorry to do just that, but I think it's more than bikeshed:
I do not think that CA po
(OT: Just culture)
On 17.12.2008 13:11, Ian G wrote:
Have they legislated that pi is 3 again?
Welcome to Europe, we hope you enjoyed your flight, and will travel on
pi airlines around the globe again :)
For the record, it was the US - Indiana specifically - which legislated
pi, see a quick
On 16.12.2008 23:04, Frank Hecker wrote:
However I suspect that S-TRUST is constrained in its practices by the
relevant German laws and/or EU directives. Unfortunately I couldn't
find any references that address this particular issue.
Even if so, such a law wouldn't preclude a root *specifical
ead it.
HTH anyways.
Ben
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
On 14.01.2009 18:49, Ian G wrote:
In _Rampell_ [2]:
"... Those audits are relied on not only by the clients on whose
financial matters audits are performed but upon a host of other
individuals and entities who may rely on the information in making
their own economic decisions. Audited statemen
On 23.01.2009 12:14, Rob Stradling wrote:
For the additional signature(s) to become especially useful, the primary
signature on the certificate would need to be substantially broken (e.g. by a
pre-image attack on the hash algorithm). But if this happened, it is likely
that the CA would revoke th
On 15.01.2009 18:27, Reed Loden wrote:
Well, if you really want to go as far as to want mozilla.org's owner
to be MoFo, what do you say about the O= in the SSL certificate for
*.mozilla.org? The O= is currently Mozilla Corporation, rather than
Mozilla Foundation.
I don't care, myself. Not sur
On 15.01.2009 16:06, Johnathan Nightingale wrote:
I see. And what if, given that the foundation is a small entity with
few full time employees, they decided to contract out the management
of the technical side of things to, e.g., the Mozilla Corporation?
They are already doing that. I am not
On 14.01.2009 20:28, Johnathan Nightingale wrote:
On 14-Jan-09, at 2:03 PM, Ben Bucksch wrote:
Foundation must hold the end of the string that controls it all -
both legally (board etc.) and technically (domain ownership, repo
backup copy (which luckily everybody has, so no problem)).
What
On 13.01.2009 23:09, Gervase Markham wrote:
Mozilla Corporation is listed as the registrant owner of mozilla.org
in WHOIS.
FWIW, I think that should be fixed. mozilla.org is owned by the project.
The project is currently is legally represented by the Foundation
(that's its purpose). It's fine
On 13.01.2009 09:48, Rob Stradling wrote:
I made a similar suggestion to ietf.pkix in October 2006. See...
http://www.imc.org/ietf-pkix/mail-archive/msg01964.html
...and the rest of that thread, including...
http://www.imc.org/ietf-pkix/mail-archive/msg01984.html
...
Ben, I agree that having
On 09.01.2009 18:51, Johnathan Nightingale wrote:
SHA-1 is heading that way as well, and the decisions we make here will
likely shape policy for SHA-1's eventual decommissioning as well.
I think it's important to prepare now that we actually *can*
decommission SHA-1. This means:
* All popular
On 09.01.2009 03:56, Julien R Pierre - Sun Microsystems wrote:
Of course, when it comes to audio and video chat, part of the very
data that's being transferred can serve to authenticate the other
party (voice print, video), somewhat reducing the need for
transport-level authentication ... This
Hi Robert,
thanks for the reply.
I think there are two major misconceptions, at least one of them my fault:
* I am not proposing to mandate that the private key stays the same
(contrary to what my original bullet list said). I am merely
proposing that the new key is signed by the
On 09.01.2009 02:15, Robert Relyea wrote:
Ben Bucksch wrote:
Advocacy:
One of the core assumptions of the x.509 world is ONE SIGNATURE, and
ONE AUTHORITY.
Thing is: There is no one authority :-). God doesn't issue SSL
certificates. Apart from him, I trust only me and my friends.
T
First off, please note that this is a proposed *change* to the PKI
system. A small change, but nevertheless a change, yes. We're trying to
make it more secure. So, "That goes against current definitions" is not
an argument, it's inherent.
No, the question OCSP asks is ... "is this cert revok
On 09.01.2009 05:32, Ben Bucksch wrote:
The OCSP responder is also allowed to forget about the revocation
status of any cert that's outside its validity period.
Our CAs would not be allowed to do that. It's fairly trivial to keep
the whole list.
P.S. That wouldn't even be str
Advocacy:
One of the core assumptions of the x.509 world is ONE SIGNATURE, and
ONE AUTHORITY.
Thing is: There is no one authority :-). God doesn't issue SSL
certificates. Apart from him, I trust only me and my friends.
Different school of thought.
Yes, definitely.
It's the reason why S/
On 01/09/2009 01:12 AM, Ben Bucksch:
It's not an *endorsement*, but making it possible to use them without
fat warning
Which is exactly the same thing...
No. "Make it possible" and "endorse" are two entirely different things.
the longer a key is used the bett
On 08.01.2009 23:15, Nelson B Bolyard wrote:
I encourage people to read through that bug, especially the early
comments, before contributing here. (The later comments are mostly "me
too")
Esp. because the first are from you (and are dissenting, and therefore
important, while agreeing comments a
On 08.01.2009 23:35, Eddy Nigg wrote:
On 01/08/2009 11:44 PM, Ian G:
Well, what Firefox does is cert-exception-click-thru-ordeal; whereas
people are asking for key-continuity-management, with perhaps the
emphasis on the last word.
Well, is it than an endorsement for self-signed certs?
It's
On 08.01.2009 22:09, Ben Bucksch wrote:
* How to deal with cert expiry
A possible solution (already posted in comment 18 in the bug):
* Require website owners to continue using the same private key.
* A fingerprint of that private key is put in the certificate.
* We store on first
https://bugzilla.mozilla.org/show_bug.cgi?id=kcm (= bug 398721)
Based on request by Johnathan in
mailman.1145.1231422435.4224.dev-tech-cry...@lists.mozilla.org , and by
Nelson in the bug (to keep out advocacy), I hereby open a thread to work
out the technical details how we could make that wor
Hi D3something,
as Ian said, ignore Skype. Look at open-source video chat apps (there
are a few). Then look at open source crypto libs (openssl, maybe NSS,
etc.), and crypto email solutions (esp. GPG), and crypto chat solutions
(e.g. GPG in Jabber) and how the key exchange works. Then think ab
On 08.01.2009 14:46, Johnathan Nightingale wrote:
- All of this would be better with KCM, which is why I filed this bug
to discuss the possibility.
https://bugzilla.mozilla.org/show_bug.cgi?id=kcm
Thank you! Fantastic proposal, thanks for having the guts to challenge
status quo and seriously
On 07.01.2009 17:16, Ian G wrote:
That is, if Phishing and Malware and XSS and website hacks and
identity-is-credit and any number of other things are causing so many
losses in the good ol' US of A and the other identity-fraught markets
... so much so that the FBI bothers to measure them ... th
On 07.01.2009 17:16, Ian G wrote:
That is, if Phishing and Malware and XSS and website hacks and
identity-is-credit and any number of other things are causing so many
losses in the good ol' US of A and the other identity-fraught markets
... so much so that the FBI bothers to measure them ... th
On 05.01.2009 01:35, Nelson B Bolyard wrote:
There's no mozilla.policy hierarchy.
It can be created.
There's already a mozilla.governance, which would fit there, too.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.moz
On 05.01.2009 01:00, Eddy Nigg wrote:
A dev.security...yes, the forgotten step child of crypto. At times
we used to post there (and cross post to crypto) and don't know why
crypto became the de-facto list for all CA/SSL/Policy related issues.
Because crypto (including CA) is just a small a
damages and win.
What I have seen in the last 2 weeks was extremely sobering. An audit
which doesn't check the actual verifications done by the CA is entirely
worthless.
See also "PositiveSSL is not valid for browsers", towards the end. I
think that CPS s
On 31.12.2008 19:57, Frank Hecker wrote:
Kyle Hamilton wrote:
Ummm... has an enterprise PKI ever been included in Mozilla?
Sorry, I wasn't being clear here. I'm not referring to enterprises
that have their own root CAs. I was referring to schemes where
enterprises work through CAs like VeriS
On 03.01.2009 18:09, Florian Weimer wrote:
Are you saying that Fluff, Inc. could get a cert for mozilla.org,
assuming Fluff, Inc reveal its legal identity?
Yes, that's the essence.
Well, that's a hole large enough that you can drive a trunk through.
I'm sure it's pretty easy to
On 03.01.2009 20:03, Eddy Nigg wrote:
On 01/03/2009 09:03 PM, Nelson B Bolyard:
I hate to say it, but it's possible for the browser user to change those
values without either (a) modifying the browser or (b) using some proxy
tool.
I don't know another way, but I'm glad to learn how.
You can
On 03.01.2009 20:01, Eddy Nigg wrote:
the other layers of defense
Please don't call the blacklist a real "layer of defense". If he didn't
try to get a cert for paypal.com, it would have worked. All layers
failed. Please be honest enough to yourself to admit that, so that you
can try to find
On 03.01.2009 15:54, Florian Weimer wrote:
The EV process does not verify ... that it is the legal entity which
controls the domain name mentioned in the Common Name field.
Are you saying that Fluff, Inc. could get a cert for mozilla.org,
assuming Fluff, Inc reveal its legal identity?
___
On 03.01.2009 16:48, Eddy Nigg wrote:
...I wouldn't be willing to disclose each and every detail of code,
preventive measures, controls and procedures and possible events.
Well, I think this might be a good idea, though. I could even go so far
as to demand that all operations of the CA, includ
ut at least not that obviously stupid, it can
really have been just an oversight of the developer in question, and his
reviewer.
Ben
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
od idea, it obviously wouldn't have prevented registration of other
targets.
So, what really happened and why? How is the browser any relevant in the
verification steps?
Ben
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
htt
Eddy Nigg wrote:
perhaps Mozilla should start to use EV
certs for the update mechanism of Firefox and *enforce* it? There might
be many other sites which potentially could wreak havoc not measurable
in terms of money only.
Very good point.
Indeed, I don't want to trust the security
On 31.12.2008 03:26, Nelson B Bolyard wrote:
Dan, I believe Paul was suggesting that he did not want to see
signatures on email messages themselves be invalidated just because
they use MD5. The email messages themselves have different
vulnerability characteristics than the signatures on the cer
FWIW:
On 31.12.2008 15:47, Eddy Nigg wrote:
EV is clearly maximum
No. EV is what I always expected all certs to be. It's really the
minimum. The whole security hangs of a phone call. It has lots of loopholes.
For me, anything less is rather pointless. DV: verify via http or
plaintext mail -
being able to get a cert for
www.bankofamerica.com or (worse) addons.mozilla.org.
Ben
On 30.12.2008 21:47, Florian Weimer wrote:
Now, 3 years later, some scammers and spammers actually notice me and
set up fake SSL sites with my certs.
Not just fake sites. Some of the OEM software
I have that option. I
don't care much about SSL for myself, I don't trust it anyways (apart
from usual bank stuff, which is IMHO and by law the bank's problem, not
mine).
Ben
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
On 30.12.2008 20:51, Frank Hecker wrote:
Ben Bucksch wrote:
"not intended for ... e-commerce. ... the certificates carry no
warranty"
Ben, this is a pretty common disclaimer that CAs (including CAs other
than Comodo, I believe) make for DV certs (i.e., certs for which only
the doma
On 30.12.2008 12:43, Ian G wrote:
PositiveSSL Certificates are low assurance level Secure Server
Certificates from Comodo ideal for mail servers and server to server
communications. They are not intended to be used for websites
conducting e-commerce or transferring data of value.
...
Due to the i
On 30.12.2008 19:50, Michael Ströder wrote:
Nelson B Bolyard wrote:
The upshot of this is probably going to be that, in a short time, all
the world's browsers (and PKI software in general) stop supporting MD5
for use in digital signatures.
It would be nice if the user could define in
rt getting
concerned and stop visiting the site when it's truning green->blue is EV
of any use.
So, that means we have the same collateral damage as now.
See thread "Just change expiry time" for an alternative reaction.
Ben
___
dev-tech-
On 30.12.2008 17:49, Chris Hills wrote:
On 30/12/08 17:47, Nelson B Bolyard wrote:
I meant to add: The paper with the real facts is seen at
http://www.win.tue.nl/hashclash/rogue-ca/
In the meantime, could a list of the affected CA's be made available
so that we may remove the trust bits from
ts as well. Partially from VeriSign. How comes? Why were they not
removed? Surely there was plenty of time to renew any cert issued under
them in the meantime.
Ben
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozill
ot be what we want in the Comodo case.
- we control the software. The NSS team can implement additional
features to support this (specifically exclude a subordinate CA cert) or
anything, when needed.
Ben
___
dev-tech-crypto mailing list
dev-tech-c
and that they have no right to put me out of business, and that even if
so, they should not yank my root anyways, because so many websites are
using it.
I smile.
Ben
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
On 30.12.2008 13:49, Michael Ströder wrote:
I see no problem the schedule the removal of a trust flag. For
security reasons all users have to update browsers from time to time
anyway. ;-}
Yup, that's the low-tech version of effectively doing the same. And it
gives more flexibility.
_
On 30.12.2008 12:43, Ian G wrote:
[Audits reliabilty]
You already opened a thread about this (and I replied there). No point
to open another sub-thread about this.
Most all certificates carry no warranty
No. This particular sentence appears under heading "Positive SSL
Certificate", as I
On 28.12.2008 14:23, Ian G wrote:
[1] disclosure, I work as an auditor
So, Ian, what are you trying to tell us? We can't yank roots. We can't
rely on audits. How are we supposed to restore and ensure proper
operation of the system?
Obviously, just trusting CAs blindly and hoping for the bes
ore
proper functioning of the system within one year (or less).
And we have a real threat to CAs.
Ben
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
On 29.12.2008 19:04, Frank Hecker wrote:
So, in theory at least a WebTrust for CAs audit is supposed to confirm
management's assertions that verification of subscriber information is
being done properly, including any verifications done by third-party
RAs acting on behalf of the CA. In practice
On 29.12.2008 07:59, Nelson B Bolyard wrote:
Perhaps the policy should even go so far, as Kai has suggested, as to
require that whatever entity performs the verification of subject
identity for the CA must be audited.
Yes. Not perhaps.
The verification is one of the two core operations of t
Background: CertStar issued certificates without verification
whatsoever. The faulty certs were signed with the PositiveSSL
certificate, which is chained to the UserTRUST root cert that Mozilla
ships. The UserTRUST cert is owned and operated by Comodo.
Our policy mandates that CAs have a valid
On 28.12.2008 12:13, Kai Engert wrote:
From my perspective, it's a CA's job to ensure competent verification
of certificate requests. The auditing required for CAs is supposed to
prove it. The verification task is the most important task. All
people and
processes involved should be part of the
David Stutzman wrote:
Then I clicked on Security (http://mxr.mozilla.org/security/)
In the "Text Search" box I typed "CERTCertificateStr" and clicked Find.
Scrolled down to:
/data/lxr-data/security/mozilla/security/nss/lib/certdb/certt.h,
* line 76 -- typedef struct CERTCertificateStr CER
David Stutzman wrote:
BTW, on an unrelated note, does anyone know the difference between
lxr.mozilla.org and mxr.mozilla.org?
#developers topic says:
please test http://mxr.mozilla.org/ the code might land as
http://lxr.mozilla.org
I originally went here:
http://mxr.mozilla.org/security/sou
(Followup-To m.d.t.crypto)
In private discussion, Eddy of StartCom suggested SSL CA certs for
* internal sites (company webmail/IMAP, VPN etc.)
* private discussion (blogs, forums, chat)
* generally everything where you supply a login/password.
I think other solutions are more appropriate
rming that
he/she did sign the applicable document". Maybe I have overlooked
something, but I could give them the address of eBay, or my address with
an eBay sign, and *my* phone number, sign the doc, and then when they
call me, greet with "Ben Bucksch of eBay speaking" and confi
Hi there,
I'd like to know does the call a local PKCS11 module, and how
does it store the key pair into the local key store and how I can know
which PKCS11 module will be used if there are more than two?
Is there any similar way for IE with a CSP?
Here is a piece of HTML code:
If y
Julien,
Just checked FF and NS. Both have the buttons of login and logout for
Security Devices. The manner you provided allows me to remove the SSL
caching, but it also erases the exisiting SSL connection. This will not
work for some situations.
Anyway, thanks a lot for your help.
Ben
Julien
Hi there,
I am running a Client-side SSL connection using Firefox browser 1.5. I
found a problem with it is the SSL caching. Open an FF browser and
started a Client-side SSL connection to a web server. It's fine.
Now I want to open a different SSL connection with a different user
account and keep
Nelson,
Thanks a lot for your helps.
Now I have found and fixed my problem. It comes from a CKA_VALUE
checking, not from the CKA_ID checking.
Nelson B wrote:
> ben wrote:
>
> > In my case both the attributes CKA_ID and CKA_LABEL are set to a same
> > unique name regardles
Nelson,
Thanks for your help. Here are my anwsers for your asking:
Some questions:
a) When you see the dialog for choosing a certificate, do the names of
the certs that appear in that dialog bear the strings from your
CKA_LABEL attributes?
I think yes. Actually the string in my CKA_LABEL a
lient auth at all?
if in the cert selection list there is a single cert, the client auth
is fine.
else fails.
- client auth with the wrong cert?
Yes.
- client auth with the right cert but a bad signature?
Nelson B wrote:
> ben wrote:
>
> > In my case both the attributes CKA_ID and
and CKA_LABEL
attributes of its cert's.
>From my log file I cannot see a reason of why the browser didn't pick
up the selected private key.
Can CKA_ID and CKA_LABEL be set to the same value or not?
Thanks again
Nelson B wrote:
> ben wrote:
>
> > I installed my PKCS1
As Nelson suggested, I post my question here.
Hi there,
I installed my PKCS11 module into the Firefox browser. I can see my
certs on my token from the Certificates Manager of the browser.
Turn on the option -- "Ask me evey time". Then I started a Client Site
SSL connection to my web server. The
opy? Might
it not be that two systems have pretty similar system directories?
(Especially as limited user accounts become more prevalent)?
-Ben
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
91 matches
Mail list logo
