Andreas Jellinghaus wrote:
> Am Mittwoch 28 Januar 2009 19:02:39 schrieb Stanislav Brabec:
> > In case of Smart Cards, it might be GID writability for "scard" group,
> > allowing to run smart card daemon without root privileges.
>
> if pcscd or openct should run as non-root, then there should be:
Andreas Jellinghaus wrote:
> Am Mittwoch 28 Januar 2009 19:30:52 schrieb Stanislav Brabec:
> > How to name the main category "smart_card_reader or crypto_token"?
>
> I think it is easer to explain, that a usb crypto token is a device consisting
> of a reduced smart card reader and a fixed build in
On 1/29/09, Andreas Jellinghaus wrote:
> Am Mittwoch 28 Januar 2009 19:02:39 schrieb Stanislav Brabec:
>
> > In case of Smart Cards, it might be GID writability for "scard" group,
> > allowing to run smart card daemon without root privileges.
>
>
> if pcscd or openct should run as non-root, then
Am Mittwoch 28 Januar 2009 19:05:08 schrieb Alon Bar-Lev:
> Running software as root is the worst solution. Especially security
> centric software.
not a good solution, but not the worst. remember old linux/unix systems
with a bin user and group, and all binaries owned by them? that was
worse. cre
Am Mittwoch 28 Januar 2009 19:02:39 schrieb Stanislav Brabec:
> In case of Smart Cards, it might be GID writability for "scard" group,
> allowing to run smart card daemon without root privileges.
if pcscd or openct should run as non-root, then there should be:
* one way how openct/pcscd can access
Am Mittwoch 28 Januar 2009 19:30:52 schrieb Stanislav Brabec:
> How to name the main category "smart_card_reader or crypto_token"?
I think it is easer to explain, that a usb crypto token is a device consisting
of a reduced smart card reader and a fixed build in smart card. I guess
this is quite cl
--On Thursday, January 29, 2009 03:36:42 AM +0100 Peter Stuge
wrote:
> Jeffrey Hutzelman wrote:
>> the USB device is entirely in the card.
>
> They are nice. I was building my own expresscard egate adapter for a
> while there.
That sounds like a useful item, and hopefully not too tricky.
Too ba
Jeffrey Hutzelman wrote:
> the USB device is entirely in the card.
They are nice. I was building my own expresscard egate adapter for a
while there.
//Peter
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.o
--On Thursday, January 29, 2009 02:58:53 AM +0100 Peter Stuge
wrote:
> Jeffrey Hutzelman wrote:
>> Something like the Reflex "reader" which is really just an egate
>> adapter.
>
> I don't think there is a USB device until the egate is inserted.
That's correct. The adapter is just a very funny
Jeffrey Hutzelman wrote:
> Something like the Reflex "reader" which is really just an egate
> adapter.
I don't think there is a USB device until the egate is inserted.
//Peter
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://w
Andreas Jellinghaus wrote:
> > We need a "category" string that covers both and use it for both,
> > otherwise we will have problems in defining generic rules (especially in
> > case, when we know, that it is ISO 7816 device, but don't know, which
> > one).
> >
> > Possibilities:
> > iso7816 = smar
On 1/28/09, Andreas Jellinghaus wrote:
> someone has a group "usb"? ouch. I don't like this proposal.
Gentoo has.
> people might think "lets add a user to that group, like we do with audio
> and video, so people can use usb devices". if then this would be implemented
> like alon suggested, a
Andreas Jellinghaus wrote:
> Am Mittwoch 28 Januar 2009 18:06:33 schrieb Alon Bar-Lev:
> > On 1/28/09, Andreas Jellinghaus wrote:
> > > > - Define policy for ACL (see freedesktop Bugzilla)
> > >
> > > root,root 0600 is fine with me. distributions could create some system
> > > account, and use th
Am Mittwoch 28 Januar 2009 18:06:33 schrieb Alon Bar-Lev:
> On 1/28/09, Andreas Jellinghaus wrote:
> > > - Define policy for ACL (see freedesktop Bugzilla)
> >
> > root,root 0600 is fine with me. distributions could create some system
> > account, and use that system account for such usb devices
On 1/28/09, Andreas Jellinghaus wrote:
> > - Define policy for ACL (see freedesktop Bugzilla)
>
> root,root 0600 is fine with me. distributions could create some system
> account,
> and use that system account for such usb devices and run pcscd and openct
> under these accounts (if that works
> We need a "category" string that covers both and use it for both,
> otherwise we will have problems in defining generic rules (especially in
> case, when we know, that it is ISO 7816 device, but don't know, which
> one).
>
> Possibilities:
> iso7816 = smart_chip*
ok, but then please name it "sma
--On Wednesday, January 28, 2009 03:41:49 PM +0100 Ludovic Rousseau
wrote:
(mostly I'm agreeing with Ludovic here and adding a few comments of my own)
> 2009/1/28 Stanislav Brabec :
>> We need a "category" string that covers both and use it for both,
>> otherwise we will have problems in defin
2009/1/28 Stanislav Brabec :
> We need a "category" string that covers both and use it for both,
> otherwise we will have problems in defining generic rules (especially in
> case, when we know, that it is ISO 7816 device, but don't know, which
> one).
>
> Possibilities:
> iso7816 = smart_chip*
Ple
Andreas Jellinghaus wrote:
> Am Dienstag 27 Januar 2009 19:14:31 schrieb Stanislav Brabec:
> > Ludovic Rousseau wrote:
> > > 2009/1/23 Stanislav Brabec :
> > > > I don't know, whether multi-slot devices use more USB devices, more USB
> > > > interfaces or only one interface and multi-slot protocol.
--On Tuesday, January 27, 2009 11:01:15 PM +0100 Ludovic Rousseau
wrote:
> 2009/1/27 Stanislav Brabec :
>> It is possible to detect form factor (credit card size, SIM size)?
>
> No. This information is not stored in any USB descriptor I know.
You certainly can't tell in all cases. For example,
Am Dienstag 27 Januar 2009 19:14:31 schrieb Stanislav Brabec:
> Ludovic Rousseau wrote:
> > 2009/1/23 Stanislav Brabec :
> > > I don't know, whether multi-slot devices use more USB devices, more USB
> > > interfaces or only one interface and multi-slot protocol.
> >
> > A multi-slot reader is just
2009/1/27 Stanislav Brabec :
> It is possible to detect form factor (credit card size, SIM size)?
No. This information is not stored in any USB descriptor I know.
> Is it the same way that can be used to detect contact less reader?
You can't detect a contactless reader from the USB descriptor. I
Ludovic Rousseau wrote:
> 2009/1/23 Stanislav Brabec :
> > I don't know, whether multi-slot devices use more USB devices, more USB
> > interfaces or only one interface and multi-slot protocol.
>
> A multi-slot reader is just one USB device. The only difference is the
> value of the bMaxSlotIndex
2009/1/23 Stanislav Brabec :
> I don't know, whether multi-slot devices use more USB devices, more USB
> interfaces or only one interface and multi-slot protocol.
A multi-slot reader is just one USB device. The only difference is the
value of the bMaxSlotIndex field in the CCID descriptor.
I don
Andreas Jellinghaus wrote:
> before I forget:
> we also have at least one card reader with wireless interface.
> it supports iso 14433A and B and mifare protocols, if I'm not mistaken.
> the code to use it is librfid.
>
> I would prefer not to use the "rfid" name in any way, since has become a
> g
before I forget:
we also have at least one card reader with wireless interface.
it supports iso 14433A and B and mifare protocols, if I'm not mistaken.
the code to use it is librfid.
I would prefer not to use the "rfid" name in any way, since has become a
generic word for very different technologi
On 1/23/09, Andreas Jellinghaus wrote:
> Am Freitag 23 Januar 2009 16:15:39 schrieb Alon Bar-Lev:
>
> > > Plus:
> > > - no udev event is generated when the device is removed
> >
> > There is, I sent you.
> > Hal get this from somewhere...
>
>
> hal remembers, udev does not. thus udev only kn
Am Freitag 23 Januar 2009 16:15:39 schrieb Alon Bar-Lev:
> > Plus:
> > - no udev event is generated when the device is removed
>
> There is, I sent you.
> Hal get this from somewhere...
hal remembers, udev does not. thus udev only knows that some usb
device is gone, but does not remember e.g. ve
(joining two sub-threads)
Andreas Jellinghaus wrote:
> new topic: usb crypto tokens
> I think we should have both "smart_card_reader" and "usb_crypto_token"
> for those token with internal smart cards (e.g. aladdin etoken pro and
> friends). it could confuse the users if we say they are smart car
Andreas Jellinghaus wrote:
> adding a few "info.capability" to the fci files is fine with me.
>
> the other side is: how these are evaluated.
>
> if I have a machine, where both gui access as well console
> login need the smart card reader, then giving exclusive rights
> to the one logged in, wil
Ludovic Rousseau wrote:
> 2009/1/23 Stanislav Brabec :
> > A separately maintained package would be another possible way to
> > distribute FDI files: Scan all available driver packages, create a list
> > of all known readers, their USB/PCI ids and capabilities (class, card
> > format,...).
>
> I
On 1/23/09, Ludovic Rousseau wrote:
> > anyway, old stories, long closed. using hald is supported upstream and
> > easier, thus it is the recommend way from my point of view.
>
>
> I have the exact same (frustrating) experience with udev and pcsc-lite.
>
> Plus:
> - no udev event is generated
2009/1/23 Andreas Jellinghaus :
> new topic: usb crypto tokens
> I think we should have both "smart_card_reader" and "usb_crypto_token"
> for those token with internal smart cards (e.g. aladdin etoken pro and
> friends). it could confuse the users if we say they are smart card readers.
Could "usb_
2009/1/23 Stanislav Brabec :
> Andreas Jellinghaus píše v Pá 23. 01. 2009 v 13:27 +0100:
>> Am Freitag 23 Januar 2009 12:59:57 schrieb Stanislav Brabec:
>> > HAL documentation recommends to discriminate between three types of FDI
>> > files:
>> > - preprobe: Actions before hal starts to identify th
Am Freitag 23 Januar 2009 14:40:18 schrieb Stanislav Brabec:
> Well, maybe "capabilities" is not a right place to add this keyword, but
> the idea remains.
agree.
> > with hal, do we need to make sure only either openct fdi file or ccid fdi
> > file is installed? or how can you manage, whether so
Andreas Jellinghaus píše v Pá 23. 01. 2009 v 13:27 +0100:
> Am Freitag 23 Januar 2009 12:59:57 schrieb Stanislav Brabec:
> > HAL documentation recommends to discriminate between three types of FDI
> > files:
> > - preprobe: Actions before hal starts to identify the device
> > - information: Collect
Am Freitag 23 Januar 2009 12:59:57 schrieb Stanislav Brabec:
> HAL documentation recommends to discriminate between three types of FDI
> files:
> - preprobe: Actions before hal starts to identify the device
> - information: Collecting information about the device
> - policy: Perform actions
>
> Cur
Andreas Jellinghaus wrote:
> > information: Identify selected devices.
> > info.category = 'smart_card_reader'
> > info.capabilities = { 'openct' }
>
> openct or some other software should not matter IMO, why make it a capability?
HAL documentation recommends to discriminate between three types o
2009/1/22 Andreas Jellinghaus :
> Am Donnerstag 22 Januar 2009 18:57:19 schrieb Alon Bar-Lev:
>> On 1/22/09, Andreas Jellinghaus wrote:
>> > using udev was a huge pain for many years, everytime I thought "now it
>> > works", a few months later openct didn't work with the new udev. I'm
>> > sick
Hello,
I have no objection to report more information about the smart card
reader at the HAL interface. But as you said we should be careful of
the names we use.
2009/1/22 Stanislav Brabec :
> Here is a short example, what I intend to do:
>
>
>
>
>
>
>
> smart_card_
On 1/23/09, Andreas Jellinghaus wrote:
> > 3. pcscd must run as root... A none root mode may be supported but
> > never implemented.
> forgive me, but usb control transfer ioctl can only be done as root I thought?
> thus anyone trying these on a usb device needs root? or is write access to
> th
Am Freitag 23 Januar 2009 01:49:05 schrieb Peter Stuge:
> Andreas Jellinghaus wrote:
> > if anyone wants to walk into the opposite direction, write a daemon
> > that monitors usb and then acts on any change, that is fine with me
> > - I think pcscd does exactly that? not sure.
>
> Implementation sh
Am Freitag 23 Januar 2009 06:51:13 schrieb Alon Bar-Lev:
> On 1/22/09, Jeffrey Hutzelman wrote:
> > How do you propose for USB device drivers to talk to their devices, if
> > not using libusb? Remember, we'd like to be portable here; the whole
> > world's not Linux.
>
> openct does not use libus
> 3. pcscd must run as root... A none root mode may be supported but
> never implemented.
forgive me, but usb control transfer ioctl can only be done as root I thought?
thus anyone trying these on a usb device needs root? or is write access to
the device enough?
> 4. Due to the threading limitati
Sorry Peter,
I have no clue how you make the connection from usb interrupt
mode to hal.
from my point of view udev is unstable and changes in udev
broke the udev/openct setup several times. the udev/hotplug/linux-usb
folks recommend to use hal instead, which so far is working fine.
so why not use
On 1/22/09, Jeffrey Hutzelman wrote:
> How do you propose for USB device drivers to talk to their devices, if not
> using libusb? Remember, we'd like to be portable here; the whole world's
> not Linux.
openct does not use libusb for communicating with usb even before I
know it exists... :)
This
Andreas Jellinghaus wrote:
> if anyone wants to walk into the opposite direction, write a daemon
> that monitors usb and then acts on any change, that is fine with me
> - I think pcscd does exactly that? not sure.
Implementation should be simple at least for Linux.
//Peter
__
Stanislav Brabec wrote:
> On the link level, USB interrupt mode is based on periodical
> re-submitting of the interrupt URB.
Yeah. USB devices can be put to sleep and signal wakeup too.
Seems our opinion is that HAL is bloat and bad for life.
Your situation does not align with this.
Obviously y
Am Donnerstag 22 Januar 2009 18:57:19 schrieb Alon Bar-Lev:
> On 1/22/09, Andreas Jellinghaus wrote:
> > using udev was a huge pain for many years, everytime I thought "now it
> > works", a few months later openct didn't work with the new udev. I'm
> > sick of that pain, and since the udev/hotpl
> information: Identify selected devices.
> info.category = 'smart_card_reader'
> info.capabilities = { 'openct' }
openct or some other software should not matter IMO, why make it a capability?
> Good idea! But iso7816 could make it more cryptic to ordinary users.
right. stick with "smart_card_r
--On Thursday, January 22, 2009 06:50:34 PM +0100 Andreas Jellinghaus
wrote:
> more complex operations such as "upload new firmware
> to card reader" will most propably never work with pcscd (guessing only,
> I'm no expert here).
I think that's going to depend on the reader driver. There cert
--On Thursday, January 22, 2009 08:49:33 PM +0200 Alon Bar-Lev
wrote:
> Poll the reader to detect card insert.
Yeah, that's still a problem, and certainly one I'd like to see fixed.
It's also per-driver, and I'm not sure it even _can_ be fixed for all kinds
of devices.
>> > 5. The udev sup
Andreas Jellinghaus wrote:
> openct already has a fci file, adding some
> information into it so gui tools can identify
> the result is not a bad idea I guess.
It's my plan to start with this file. This file uses "smart_card_reader"
for category. HAL specification recommends to use two FDI files i
On 1/22/09, Jeffrey Hutzelman wrote:
> --On Thursday, January 22, 2009 08:14:20 PM +0200 Alon Bar-Lev
> wrote:
>
>
> > Well, Ludovic knows my arguments...
> >
>
>
> > 4. Due to the threading limitation of libusb or kenrel pcscd polls
> > readers every 2 seconds which waste CPU and power resources
--On Thursday, January 22, 2009 08:14:20 PM +0200 Alon Bar-Lev
wrote:
> Well, Ludovic knows my arguments...
> 4. Due to the threading limitation of libusb or kenrel pcscd polls
> readers every 2 seconds which waste CPU and power resources.
Only if you have reader drivers which require this. I
Andreas Jellinghaus wrote:
> Am Donnerstag 22 Januar 2009 15:54:07 schrieb Stanislav Brabec:
> > > But why do you need to configure PolicyKit? What is the problem
> > > PolicyKit is trying to solve?
> >
> > Grating access to users physically present at the computer.
> > It uses standard UNIX ACL, s
On 1/22/09, Jeffrey Hutzelman wrote:
> >
> > > Yes, udev supports it as well. But most vendors prefer HAL for this
> > > purpose nowadays.
> > >
> >
> > vendors? You mean Novell, right?
> >
>
> Most of the major Linuxes, both commercial and otherwise.
> I believe Sun is also going down this pat
adding a few "info.capability" to the fci files is fine with me.
the other side is: how these are evaluated.
if I have a machine, where both gui access as well console
login need the smart card reader, then giving exclusive rights
to the one logged in, will break console login?
I understand the
On 1/22/09, Andreas Jellinghaus wrote:
> using udev was a huge pain for many years, everytime I thought "now it
> works", a few months later openct didn't work with the new udev. I'm sick
> of that pain, and since the udev/hotplug/linux-usb folks tell us to use hal,
> and hal seems to work, I
Am Donnerstag 22 Januar 2009 15:54:07 schrieb Stanislav Brabec:
> > But why do you need to configure PolicyKit? What is the problem
> > PolicyKit is trying to solve?
>
> Grating access to users physically present at the computer.
> It uses standard UNIX ACL, so it can apply to both device nodes and
openct already has a fci file, adding some
information into it so gui tools can identify
the result is not a bad idea I guess.
please don't use "card_reader", we already have trouble with people
only knowing comptact flash / smart media cards / ... and being confused
by what we call "smart card".
Jeffrey Hutzelman wrote:
> > PolicyKit may be useful for pcsc-lite/openct as well, to block remote
> > users access to daemon.
>
> I'm not sure how you intend to do that, or even that it's a good idea.
You can apply policy on /var/run/pcscd/pcscd.comm. (Not tested yet.)
> In
> fact, I'm pretty
Jeffrey Hutzelman wrote:
> >> > HAL recognizes Smart Card readers as unknown USB devices
> >> Why is that a problem? Why do you need HAL to know about smart card
> >> readers?
> > HAL detects correctly music players, scanners, fingerprint readers,
> > UPSes (well, just only HID). Why Smart Cards
2009/1/22 Stanislav Brabec :
> Ludovic Rousseau wrote:
>> 2009/1/22 Stanislav Brabec :
>
>> > HAL recognizes Smart Card readers as unknown USB devices
>>
>> Why is that a problem? Why do you need HAL to know about smart card readers?
>
> HAL detects correctly music players, scanners, fingerprint re
Alon Bar-Lev wrote:
> On 1/22/09, Stanislav Brabec wrote:
> > USB peripheral cannot initiate transfer, so USB requires some type of
> > polling by design.
>
> As far as I know and tried USB support interrupt mode, checkout the
> openct trunk ccid driver.
On the link level, USB interrupt mode i
--On Thursday, January 22, 2009 03:54:07 PM +0100 Stanislav Brabec
wrote:
> Ludovic Rousseau wrote:
>> 2009/1/22 Stanislav Brabec :
>
>> > HAL recognizes Smart Card readers as unknown USB devices
>>
>> Why is that a problem? Why do you need HAL to know about smart card
>> readers?
>
> HAL detect
--On Thursday, January 22, 2009 01:18:44 PM +0100 Stanislav Brabec
wrote:
>> I cannot
>> imagine any vendor shipping policy that would allow ordinary users
>> direct access to smartcard devices.
>
> openSUSE has to do it, at least for selected readers, otherwise users of
> these applications co
--On Thursday, January 22, 2009 02:57:10 PM +0200 Alon Bar-Lev
wrote:
> On 1/22/09, Stanislav Brabec wrote:
>> Alon Bar-Lev wrote:
>> > On 1/21/09, Stanislav Brabec wrote:
>> Yes, udev supports it as well. But most vendors prefer HAL for this
>> purpose nowadays.
>
> vendors? You mean Novel
On 1/22/09, Stanislav Brabec wrote:
> USB peripheral cannot initiate transfer, so USB requires some type of
> polling by design.
As far as I know and tried USB support interrupt mode, checkout the
openct trunk ccid driver.
Alon.
___
opensc-devel mail
Ludovic Rousseau wrote:
> 2009/1/22 Stanislav Brabec :
> > HAL recognizes Smart Card readers as unknown USB devices
>
> Why is that a problem? Why do you need HAL to know about smart card readers?
HAL detects correctly music players, scanners, fingerprint readers,
UPSes (well, just only HID). Wh
Alon Bar-Lev wrote:
> On 1/22/09, Stanislav Brabec wrote:
> > Alon Bar-Lev wrote:
> > > This is why you have udev, right?
> > Yes, udev supports it as well. But most vendors prefer HAL for this
> > purpose nowadays.
> vendors? You mean Novell, right?
Not only Novell. GNOME desktop use HAL and
2009/1/22 Stanislav Brabec :
> Reading the discussion, I want to clarify the original problem and
> needed help:
>
> Primary problem:
>
> HAL recognizes Smart Card readers as unknown USB devices
Why is that a problem? Why do you need HAL to know about smart card readers?
I guess it is directly lin
On 1/22/09, Stanislav Brabec wrote:
> Alon Bar-Lev wrote:
> > On 1/21/09, Stanislav Brabec wrote:
>
>
> > > 1) There are applications, that need direct access to the reader, not
> > > using pcsc-lite (example: cyberjack utilities). That is why it should
> > > allow to access not only to pcsc
2009/1/22 Stanislav Brabec :
> Ludovic Rousseau wrote:
>> PC/SC provides a method to detect reader insertion/removal. HAL is not
>> needed here.
>
> Yes, it is. But HAL broadcasts generic device removal events. One has to
> connect to pcscd to just identify, whether unknown USB device is a Smart
>
Reading the discussion, I want to clarify the original problem and
needed help:
Primary problem:
HAL recognizes Smart Card readers as unknown USB devices
Proposal to fix:
- Add a keyword for info.category (one word for device is permitted) to
describe the device (other devices use for example
Jeffrey Hutzelman wrote:
> > 1) There are applications, that need direct access to the reader, not
> > using pcsc-lite (example: cyberjack utilities).
>
> And how do these devices know how to talk to readers? Do they have their
> own reader drivers, separate from those included with pcsc-lite o
Ludovic Rousseau wrote:
> 2009/1/21 Stanislav Brabec :
> > Alon Bar-Lev wrote:
> >> I don't understand the motivation.
> >> Why do you care if readers are accessible by all users?
> >
> > 1) There are applications, that need direct access to the reader, not
> > using pcsc-lite (example: cyberjack u
Alon Bar-Lev wrote:
> On 1/21/09, Stanislav Brabec wrote:
> > 1) There are applications, that need direct access to the reader, not
> > using pcsc-lite (example: cyberjack utilities). That is why it should
> > allow to access not only to pcsc daemon, but also to users.
>
> This is why you have
2009/1/21 Stanislav Brabec :
> Alon Bar-Lev wrote:
>> I don't understand the motivation.
>> Why do you care if readers are accessible by all users?
>
> 1) There are applications, that need direct access to the reader, not
> using pcsc-lite (example: cyberjack utilities). That is why it should
> all
--On Wednesday, January 21, 2009 07:27:03 PM +0100 Stanislav Brabec
wrote:
> Alon Bar-Lev wrote:
>> I don't understand the motivation.
>> Why do you care if readers are accessible by all users?
>
> 1) There are applications, that need direct access to the reader, not
> using pcsc-lite (example:
On 1/21/09, Stanislav Brabec wrote:
> Alon Bar-Lev wrote:
> > I don't understand the motivation.
> > Why do you care if readers are accessible by all users?
>
>
> 1) There are applications, that need direct access to the reader, not
> using pcsc-lite (example: cyberjack utilities). That is why
Alon Bar-Lev wrote:
> I don't understand the motivation.
> Why do you care if readers are accessible by all users?
1) There are applications, that need direct access to the reader, not
using pcsc-lite (example: cyberjack utilities). That is why it should
allow to access not only to pcsc daemon, bu
I don't understand the motivation.
Why do you care if readers are accessible by all users?
On 1/21/09, Stanislav Brabec wrote:
> Hallo.
>
> I just filled a proposal for a new HAL (Hardware Abstraction Layer,
> http://hal.freedesktop.org/ ) category recognized by PolicyKit.
>
> Here is a propos
Hallo.
I just filled a proposal for a new HAL (Hardware Abstraction Layer,
http://hal.freedesktop.org/ ) category recognized by PolicyKit.
Here is a proposed solution:
http://bugs.freedesktop.org/show_bug.cgi?id=19663
Feel free to comment it there.
I am unsure, whether it makes sense to populat
84 matches
Mail list logo
