t;
> See the message with the subject "Re: [PATCH] Missing loop end check in
> crypto/engine/eng_table.c" from Geoff Thorpe. In short: the bug is
> already corrected in the CVS.
Actually, only the sk_value() case was addressed, so the report is valid
w.r.t. sk_set(). I'
someone else hasn't already nailed it by then.
Quick question: is this occuring in the head of CVS or just release
branches?
Cheers,
Geoff
--
Geoff Thorpe
[EMAIL PROTECTED]
http://www.geoffthorpe.net/
_
by making sk_value()
return NULL for out-of-range indexes, making the stack API a little more
robust and, by no coincidence, enforcing a behaviour I'd been relying on
in eng_table.c that had never actually existed.
Cheers,
Geoff
--
Geoff Thorpe
[EMAIL PROTECTED]
htt
Can you please resubmit the patch as an attachment rather than inlining
it? The patch gets word-wrapped otherwise and is unusable.
--
Geoff Thorpe, RT/openssl.org
__
OpenSSL Project http
want to update the
patch, please submit it to the request-tracker and assign it to me if you
like.
Cheers,
Geoff
--
Geoff Thorpe
[EMAIL PROTECTED]
http://www.geoffthorpe.net/
__
OpenSSL Project
nature, but as
Richard pointed out (correcting my stupidity in the process) the current
prototypes are probably ok after all because the single "length"
parameter is for the input.
Cheers,
Geoff
--
Geoff Thorpe
[EMAIL PROTECTED]
http://www.geoffthorpe.net/
__
I'm not keen to get too deep into thinking this through
nor implementing, I've got enough on my plate with the BIGNUM stuff and
some apache/shmcb hassles ...
> geoff> I think this is just one of those things that doesn't warrant
> geoff> us messing with it right now - if
Jim was having trouble getting this to the list, so I'm forwarding on his
behalf.
-- Forwarded Message --
Subject: Re: a bug in RSA_public_encrypt with RSA_NO_PADDING
Date: March 25, 2004 12:07 pm
From: Jim Schneider <[EMAIL PROTECTED]>
To: Geoff Thorpe <[E
x27;t warrant us messing
with it right now - if someone cares enough, they could clarify the
relevant docs.
Cheers,
Geoff
--
Geoff Thorpe
[EMAIL PROTECTED]
http://www.geoffthorpe.net/
__
OpenSSL Project
On March 25, 2004 09:03 am, Richard Levitte - VMS Whacker wrote:
> In message <[EMAIL PROTECTED]> on Wed, 24 Mar
> 2004 10:40:14 -0500, Geoff Thorpe <[EMAIL PROTECTED]> said:
>
> geoff> Well I was meaning counter-intuitive at the nit-picking level
> geoff> more th
Thanks for the update.
You mentioned off-RT that there might have been some other problem with
session caching? Contrary to what I said at the time, I'm closing this
ticket (for the sake of clarity). Please feel free to open another if
you hit other problems.
_
anything warranting CVS action. To my mind, they *both* RSA_NO_PADDING
and RSA_ALREADY_PADDED mean "don't prepend any padding", but only one of
them means "because I've already ensured the required conditions are
met". But other readings are possible (and clearly,
y. Your solution is right (from
outside the API), zero-pad the input to be the same number of bytes as
the RSA modulus. However, the explanation seemed wrong or at least
misleading - the conceptual problem is not the algorithm, it's the API.
Cheers,
Geoff
--
Geoff Thorpe
[EMAIL P
inking and a few others too, but they will require a lot of cleanup to
continue on the current code first so that a broader (and less urgent)
plan can be made for a future version to tackle these issues. In
particular, this requires a break with the current API in a few ways and
so involves goi
you used, and assign the ticket to me (if it lets
you, otherwise mail me the tracking number).
Cheers,
Geoff
--
Geoff Thorpe
[EMAIL PROTECTED]
http://www.geoffthorpe.net/
__
OpenSSL Project h
And even more luck to the companies and organisms who ungenerously base
their operations on the goodwill and dwindling resources of unpaid
experts.
Regards,
Geoff
PS: Chris, this isn't addressed at you at all - your observation is
perfectly valid. This post had been brewing for a while, you jus
ithmetic relationship between
sequences of keys, even if only in small batches.
Cheers,
Geoff
--
Geoff Thorpe
[EMAIL PROTECTED]
http://www.geoffthorpe.net/
__
OpenSSL Project
acks - but I guarantee that I
won't even think about it until I'm done with this bignum stuff. You may
be able to find the discussion threads in the archives somewhere (unless
I was silly enough to have raised this only on openssl-team - hmm - let
me know if you can't find anyth
Is this when I should go "Mwahahahahaha", and then not do anything,
> leaving you to wonder what you missed? :-)
Let's see ... how do I combine "openssl rand -base64", xargs, and a sed
for "VMS"? ... [1] :-)
Cheers,
Geoff
[1] PS: I was thinking inst
mess with
this in the mean time, I've got too many diffs lying round already and
this could upset my audit apple-cart :-)
Cheers,
Geoff
--
Geoff Thorpe
[EMAIL PROTECTED]
http://www.geoffthorpe.net/
__
OpenSSL Projec
On December 1, 2003 05:53 pm, Lev Walkin wrote:
> Geoff Thorpe wrote:
> > As part of the general hackathon/audit we're doing in crypto/bn/ I
> > once again came across the curious zeroing code in bn_expand2, only
> > this time I figured it was high time for me to act
partly because this sort of thing is
not really the focus for me at the moment. I'm just querying out of
interest. TIA.
Cheers,
Geoff
--
Geoff Thorpe
[EMAIL PROTECTED]
http://www.geoffthorpe.net/
_
quot; tools, then build openssl with debugging
flags and just watch s_server or s_client from a debugger. You could set
breakpoints on SSL_accept, SSL_connect, SSL_read, [etc] and just keep an
eye on the SSL structure and the SSL_METHOD tab
Of course you already *have* implemented this as #if<_foo>#else#endif
rather than #if<_foo>#endif - forgive the oversight/hallucinations, it will
teach me to look at too many things at once. Hopefully the rest of my
feedback is still valid though ...? :-)
g changes won't - the development head uses a
different scheme for building shared libraries.
Cheers,
Geoff
--
Geoff Thorpe, RT/openssl.org
__
OpenSSL Project http://www.openssl.or
py in but no handlers for the
internal implementation to request more - perhaps I'm confused though).
> Listen, I'll code and show you the patch, then you can judge for
> yourself. Deal?
:-) Sure, I'll try and take a closer look in the next day or two.
Cheers,
n't go through the ncipher RAND implementation.
But that's a philosophical suggestion. I haven't looked at the code so
have no idea off the top of my head how easy this would be to do. However
without something like this, I can imagine that linking
On November 22, 2003 05:40 pm, Dr. Stephen Henson wrote:
> On Sat, Nov 22, 2003, Geoff Thorpe wrote:
> > BTW: are you sure that it's not just a question of the ncipher
> > RAND_METHOD implementation being over-enthusiastic? I'm looking at
> > "hwcrhk_rand&q
see that the "bytes()" and "pseudorand()" handlers are
linked to the same hwcrhk_rand_bytes() function. Presumably only
"bytes()" *needs* to come from the hardware/driver - and "pseudorand(
he engine is handled in a specialised way. Food for thought.
Hmm ... indeed. The irritating thing (nothing we can do about it though)
is that application authors are probably not going to pay any attention
to the new ENGINE_METHOD_RAND_SEED flag. I know, I'm a cynic. :-)
Cheers,
Geoff
--
Ge
ll, it's arguably a more *honest* solution than vtable-switching that
cuts the ncipher out of ongoing PRNG duties and leaving it for seeding
only. But the thing that worries me more than this is to what extent we
can change underlying PRNG-mechanics in a stable branch. Particularly one
t
ignored by ENGINE API
commands that "set defaults". Ie. allow engines to offer implementations
purely as utilities, that should not be used as fallbacks (you only get
them if you specify them directly on a context-by-context basis).
Dunno, what do you think?
Cheers,
during the handshake or renegotiation phase, you
get the SSL/TLS equivalent of a "carrier disconnect" - no amount of
sequencing logic in the application protocol will matter as this
corruption in the handshake protocol will prevent application protocol
data from being exchanged anyway.
C
On November 18, 2003 08:46 pm, Lev Walkin wrote:
> Geoff Thorpe wrote:
> > Hey Lev,
> >
> > On November 18, 2003 08:28 pm, Lev Walkin wrote:
> >>This is really a very small issue, but it bothers us for quite a
> >> while.
> >
> > Which version
Hey Lev,
On November 18, 2003 08:28 pm, Lev Walkin wrote:
> This is really a very small issue, but it bothers us for quite a while.
Which version are you seeing this in? IIRC, I corrected this same clash in
CVS.
Cheers,
Geoff
--
Geoff Thorpe
[EMAIL PROTECTED]
http://www.geoffthorpe.
On November 2, 2003 08:31 am, Ben Laurie wrote:
> Geoff Thorpe wrote:
> > - There are other things to fix/change - including making the
> > existing macros and functions stop tolerating two representations of
> > zero, this may highlight more crappy code elsewhere. But on
t to put this stuff in to CVS, as it will make
collaboration easier and may give some people less reason to ignore it.
Any objections?
Any feedback would be most welcome.
Cheers,
Geoff
--
Geoff Thorpe
[EMAIL PROTECTED]
http://www.openssl.org/
___
se 'bc' is
typically built using GMP, but if it's using crypto/bn on OpenBSD then
that might become somewhat surreal :-) BTW: take a check around inside
test/ if you feel like fiddling, that's where the self-tests are
organised. FWIW, Ulf wrote some routi
On October 29, 2003 03:35 pm, Nils Larsch wrote:
> On Tuesday 28 October 2003 05:44, Geoff Thorpe wrote:
> ...
>
> > inconsistent state. BTW: my definition of a consistent state for a
> > bignum x is for it to be invariant under bn_fix_top(). It's a
>
> what about:
nges into cvs. Eg. anyone
implementing their own implementations of RSA, DSA, elliptic-curve, [etc]
or maintaining interfaces to other PKC libraries or hardware might be
affected. Before figuring out how best to continue, I'll wait to see what
(i
ms to be
responsible for a lot of complexity that could disappear if
v2-compatibility/formatting wasn't required. To this end, I think having
a wrapper for protocol versions with a 0x03 major would allow a nice
migration path. Client code could switch to it stra
more robust against this sort of problem when
supporting interoperability with any future versions of the protocol, but
v2 seems to be like a lead weight, and merely having interoperability
with it seems to cost us the security benefits of the fixes that were
introduced after v2.
Cheers,
Geoff
on that the
vtable-gymnastics in the v23 wrapper might need to be replicated for v31.
Ie. perhaps we'll need a new negotiator-method just for versions with
major number 0x03? Then again, perhaps this is already "there" but I jus
rs,
Geoff
[EMAIL PROTECTED] - Mon Sep 29 16:22:53 2003]:
> The following patch adapts that already in #668 to leave software
> fallback off except when explicitly requested, per Geoff Thorpe's
> request.
[snip]
tHello. In
particular, the handling of the handshake MAC might get a bit slimy in
the client and server code, and there may be protocol-related reasons why
this can't be deterministic anyway. (Thanks Richard for reminding me to
dump these thoughts BTW, though I've not helped much
Hi there,
On September 25, 2003 02:29 pm, Otto Moerbeek wrote:
> On Thu, 25 Sep 2003, Geoff Thorpe wrote:
> > I would go one step further and suggest that BN_cmp() and operations
> > like it that should treat their inputs as "const" should not modify
> > the
the
ideal opportunity to audit the BIGNUM code properly for this sort of
thing. In particular, it would be nice if the result of this work would
also allow us to better constify the BIGNUM API (in CVS HEAD of course,
the stable branches would merely benefit from cleaner implementations;-).
Che
way round, I won't make that stand in
> the way of having the facility available.
Perhaps just think on what I've said and/or discuss it with others before
deciding how you really want this to behave "out of the box". (Pun
intended :-).
Cheers,
Geoff
--
Geoff Thorpe
[EMAI
;ll try to remember
to go and check this later).
Cheers,
Geoff
--
Geoff Thorpe
[EMAIL PROTECTED]
http://www.geoffthorpe.net/
__
OpenSSL Project http://www.openssl.org
Development Mailing List
Audit the ENGINE implementations to eliminate "transparent" behaviour that
is not requested by the application (ENGINE_ctrl()) or the user (conf or
environment variables). This mainly covers fallback to software.
--
Geoff Thorpe, RT/o
Hi Colin,
On September 19, 2003 01:16 pm, Colin Watson wrote:
> On Wed, Sep 17, 2003 at 10:23:46AM -0400, Geoff Thorpe wrote:
[snip]
> > have time for. If yours arrives on a busy day (or during a period
> > when the person who should deal with it is away) then there are good
>
ime to change them and get the appropriate people (who have the
hardware) to verify the results.
Anyway, dump your patch into RT and let me know and we'll take a look.
Cheers,
Geoff
--
Geoff Thorpe
[EMAIL PROTECTED]
http://www.geoffthorpe.net/
_
what your system is and where your
openssl package comes from, I can't really help. Need more input...
Cheers,
Geoff
PS: I should admit that I didn't checkout/download 0.9.7b to try this, as
my current trees are 0.9.7a and 0.9.7c-dev (unreleased). So if you run
out of ideas, you sh
rs earlier in your
$PATH than the system's bundled version.
Cheers,
Geoff
--
Geoff Thorpe
[EMAIL PROTECTED]
http://www.geoffthorpe.net/
__
OpenSSL Project http://www.openssl.org
Develop
./../../../openssl/include/crypto.h:194: parse error before `STACK'
> ../../../../openssl/include/crypto.h:194: warning: no semicolon at end
> of struct or union
>
> Am I missing something obvious here?
./crypto/stack/ perhaps?
Cheers,
Geoff
--
Geoff Thorpe
[EMAIL PR
ntioned on the website somewhere with
appropriate addresses).
Cheers,
Geoff
--
Geoff Thorpe
[EMAIL PROTECTED]
http://www.geoffthorpe.net/
__
OpenSSL Project http://www.openssl.org
Development Mail
r behavioural problems lurking that might have required the
memset in the first place. Should be in CVS shortly, and so the next
nightly snapshots too.
Cheers,
Geoff
--
Geoff Thorpe
[EMAIL PROTECTED]
http://www.geoffthorpe.net/
___
at can be done?
[snip]
That is the correct way to turn off blinding - but I'd *really* appreciate
if you could dig a little on what you were observing. I don't currently
have hardware with which to test this out in the obvious fashion, and I'd
like to know what is wrong with rs
s, so I'm
officially giving up on this ticket now. :-)
--
Geoff Thorpe, RT/openssl.org
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTE
an openssl-based app under instrumentation and
*look* for uses of uninitialised data, add "-DPURIFY" to your configure
line. Please also search the archives for words like "Valgrind",
"Purify", "uninitialised memory", etc. This
e visible
in the next snapshot.
Cheers,
Geoff
--
Geoff Thorpe, RT/openssl.org
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automa
access to uninitialised data as bad -
after all, you never know *what* the memory might be set to. This of
course is exactly the property you want to stir into the randomness pool
...
Cheers,
Geoff
--
Geoff Thorpe
[EMAIL PROTECTED]
http://www.openssl.org/
_
;ex_data = 0;" then?
erm, ex_data is not a pointer, it is a CRYPTO_EX_DATA structure.
&ex_data is a pointer, of course.
Anyway, looking at the implementation of CRYPTO_free_ex_data(), I can't
understand why any cleanse/memset is required anyway? R
* Geoff Thorpe via RT ([EMAIL PROTECTED]) wrote:
>
> I've attached a diff that I think addresses the problem but I'll need to
[snip]
And as usual, the diff is attached in RT but doesn't get propogated to
the mail to openssl-dev. Please go there to pick it up.
--
Geoff Th
of how this could affect
existing (and 3rd party and future) DSA implementations. Could you
please try this out with your ubsec support and see if the handling of
fallback to software is better (at least with respect to segfaul
g with
0.9.7 or snapshots (ie. CVS development leading up to 0.9.8). Can you
confirm this misunderstanding of versions, or are you working with a
custom source tree?
Cheers,
Geoff
--
Geoff Thorpe, RT/openssl.org
__
OpenSSL Pr
I've committed the patch I wrote for this a while ago, as there have
been no complaints. It's in CVS now and should be available in snapshots
leading up to 0.9.8. Ticket resolved.
--
Geoff Thorpe, RT/openssl.org
d this
change to the head of CVS only (ie. for 0.9.8). I'll consider putting it
the 0.9.7 branch after the release, but it's certainly not urgent.
--
Geoff Thorpe, RT/openssl.org
__
OpenSSL Project
[geoff - Wed Feb 5 01:37:55 2003]:
--snip--
> request tracker). Anyway, does this seem to do what's required?
Damn, let's try that again ... the diff *is* now attached to the RT ticket.
--
Geoff Thorpe, R
e to openssl-dev though, so I guess you have to surf the
request tracker). Anyway, does this seem to do what's required?
--
Geoff Thorpe, RT/openssl.org
__
OpenSSL Project http://www.openssl.or
I haven't tried (migrating your original
patch the other direction worked in this fashion, however).
--
Geoff Thorpe, RT/openssl.org
__
OpenSSL Project http://www.openssl.org
Development Maili
- but I'll wait for the
resubmission before analysing this properly (could just be me being
obtuse and scanning the diff too quickly ...)
--
Geoff Thorpe, RT/openssl.org
__
OpenSSL Project
ng of that suggests that you copy the email to [EMAIL PROTECTED]
and [EMAIL PROTECTED]
As for the patch itself, I'll follow up in the original ticket shortly.
This ticket is now closed.
--
Geoff Thorpe, RT/openssl.org
tion is incompatible if
OPENSSL_NO_ENGINE is defined (or undefined, as the case may be).
IMHO OPENSSL_NO_ENGINE shouldn't change structure definitions, it should
change only the building of openssl implementation code.
Cheers,
Geoff
--
Geoff Thorpe
[EMAIL PROTECTED]
http://www.openssl.org/
on).
This means no ENGINE gets magically used without the application's
explicit say-so.
Suggestions for improvements in the behaviour or implementation are
welcome, and "diff -u" patches to make such changes are even more
welcome. :-)
Sorry if that's more than you wanted - I t
ld explain, as it
should then be an integer and NULL is more typically a pointer. Can you
check the man pages to confirm/deny any of this and/or try using a zero
in place of the NULL?
Cheers,
Geoff
--
Geoff Thorpe
[EMAIL PROTECTED]
http://www.openssl.org/
__
* Richard Levitte - VMS Whacker ([EMAIL PROTECTED]) wrote:
>
> Geoff, may I suggest that you either resolve #401 or set the milestone
> "0.9.8" on it (since it looks like you want to do something more with
> it for 0.9.8)?
Yep, done. Thanks.
Cheers,
Geoff
--
Geoff T
et open, and attempt to
rebadge it with a 0.9.8 milestone shortly. However as far as 0.9.7 is
concerned, this should now be sorted ...
--
Geoff Thorpe, RT/openssl.org
__
OpenSSL Project http:/
CRYPTO_w_unlock(CRYPTO_LOCK_SSL);
> > + }
>
> Just curious: why the nested "if (init_ciphers) .."?
Because once load_ciphers() is called by the first thread to win the
race (during which any competing threads will be waiting on the lock),
future passes through this code won'
es were you should run a
test outside the lock first? Ie.
if (init_ciphers)
{
CRYPTO_w_lock(CRYPTO_LOCK_SSL);
if (init_ciphers) load_ciphers();
CRYPTO_w_unlock(CRYPTO_LOCK_SSL);
}
Cheers,
Geoff
--
Geoff Thorpe
[EMAIL PROTECTED
if others want to use the pod files
directly they can obtain versions of the "pod" tools that can handle
them.
I think with 0.9.7 in beta, I will try to replace the "=head3" items
with something else in the 0.9.7 branch, but leave it as-is in th
static vs dynamic stuff is already a little too inconsistent, and both
don't really offer much room to implement clever locking schemes at all.
However, for 'chil' and 0.9.7, the issue seems to be more with Apache2.
Cheers,
Geoff
--
Geoff Thorpe
[EMA
have vendors supply
ENGINE implementations natively to their clients in the form of shared
libraries (closed-source if they want - it's not our problem) and
OpenSSL's ENGINE architecture can bind to those libraries directly. Ie.
no need for any per-ENGINE shims built into OpenSSL.
But per
that it can be looped more than once. If you allow that loop count to be
set to zero then that could provide an option for disabling memory
sanitisation altogether if people don't care... hmm.
Anyway, w.r.t. adding a memset - I can't see how that improves anything
and can see possibili
On December 8, 2002 10:02 am, Nils Larsch wrote:
> there is small memory leak in rsa_gen.c (see attached patch).
Ah cool, thanks for casting an eye over this :-)
Cheers,
Geoff
--
Geoff Thorpe
[EMAIL PROTECTED]
http://www.geoffthorpe.net/
The bastards have beaten off rationalism for now,
ater (0.9.7 has been a long time coming, I
don't think 0.9.8 should be such a big gap).
Cheers,
Geoff
--
Geoff Thorpe
[EMAIL PROTECTED]
http://www.geoffthorpe.net/
The bastards have beaten off rationalism for now, but haven't eliminated
our capacity for r
patibility
purposes if required.
(Note this approach keeps compression code in BIOs without duplicating it
in ssl/, so applications can use the BIOs independantly too. Also, new
compression methods are easier to add - eg. define a libbzip2-based BIO
and add a new compression id+hook in the
tight loop and the compilers are
generating slow "cleanse" functions.
Cheers,
Geoff
--
Geoff Thorpe
[EMAIL PROTECTED]
http://www.geoffthorpe.net/
Strange yet thought-provoking time of year;
Muslims spend a month of Rammadan, fasting and reflect
ible for handling
compression - it would just handle it on the application data before
applying the SSL/TLS framing rather than compressing data inside it. From
the application point of view, there's no need to implement anything. Did
you misunderstand me or vice versa?
Cheers,
Geoff
--
--> write_BIO --> zlib_BIO --> >--\
[app] [SSL] socket_BIO
<-- read_BIO <-- zlib_BIO <-- <--/
?
Cheers,
Geoff
--
Geoff Thorpe
[EMAIL PROTECTED]
http://www.geoffthorpe.net/
x27;ll get to backfit some RFC to it. At least that way
around, the dog wags the tail I suppose ... :-)
Cheers,
Geoff
--
Geoff Thorpe
[EMAIL PROTECTED]
http://www.geoffthorpe.net/
__
OpenSSL Project
I'm closing this ticket now. Things seem to be in order - if not,
someone should open a new ticket with specific pointers to what it is
they feel is wrong/missing. Steve-H also took a quick glance at the man
pages and didn't see anything amiss.
--
rsion of Jeffrey's more concise explanation!
:-)
> On Thu, 2002-10-31 at 10:26, Jeffrey Altman wrote:
> > You cannot use OOB data with SSL/TLS.
Cheers,
Geoff
--
Geoff Thorpe
[EMAIL PROTECTED]
http://www.geoffthorpe.net/
Well, I've had no reply from Doug MacEachern about this ticket.
Without it being resubmitted with a CC to the American icon of legal
common sense (the BXA), I can't really (read: won't) touch it. If
anyone's got any better ideas (or lives next door to Doug), please let
me know.
Cheers,
Geoff
--
I committed fixes for all this stuff quite some time ago but forgot to
close the ticket ...
--
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTE
I've committed a fix for this that the "requestor" has tested, so I'm
closing the ticket as well.
--
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL
ould, and now implements a buggy mix of
what it used to implement and what Apache2/mod_ssl needs).
I'll try and put a patch together later for review (and perhaps Nadav
you would be able to grind it through your existing test
s
desired in Apache2/mod_ssl.
Any thoughts? I'm thinking out loud here - but will continue to think a
little more carefully (and quietly) about it.
Cheers,
Geoff
--
Geoff Thorpe
[EMAIL PROTECTED]
http://www.geoffthorpe.net/
_
Hi there,
On Tuesday 08 Oct 2002 9:01 am, Frederic DONNAT wrote:
> I'd like to know the better way to be fault tolerant when using a
> cryto accelerator through an engine.
An ENGINE handle (functional reference) is attached to each key
structure (RSA, DSA, etc) upon creation and released on des
get on - I would try and keep it as orthogonal to what exists
in the source as possible, eg. by using a OPENSSL_NO_ENGINE directive that
literally makes the entire ENGINE abstraction "go away" as with the other
"no-***" options. Whether the various fine-grained d
101 - 200 of 368 matches
Mail list logo
