Thread: Re: [Easyb2k-devel] Application Structure
Status: Pre-Alpha
Brought to you by:
wyrm
From: Thomas R. <tre...@ya...> - 2007-10-30 23:02:33
|
Hi Marcos,=0AI can see how the daemon is launched as soon as a device is pl= ugged in, via HAL.=0ABut how can the daemon start a certain glue software (= and maybe the associated VoIP app)? How can one determine how many VoIP app= s are installed? And what is a VoIP ping?=0AYour pt. 3b looks more practica= l than 3a but glue software might be part of the VoIP app and started with = it, not by the daemon, couldn't it?=0AAs long as we do not have nailed down= the top-level design and the interfaces between the components (at least t= o some point) I do not think checking in libyealink makes much sense! It su= re can serve as one of the sources for the device plugin but probably does = not resemble the future device plugin. (BTW, I would also like the plugin t= o be renamed a bit.)=0ARegards,=0A-Thomas=0A=0A=0A----- Original Mail ----= =0AVon: Marcos <ma...@un...>=0AAn: eas...@li...urceforg= e.net=0AGesendet: Dienstag, den 30. Oktober 2007, 21:38:21 Uhr=0ABetreff: R= e: [Easyb2k-devel] Application Structure=0A=0AHi!=0A=0AFirst of all, I beli= ve the yealink devices can be abstracted to a=0A generic yealink devices, w= ith=0Acapabilities. Thomas did a great job on his libYealink about that. = =0A=0AOur design is by now it extremely complicated. Skypemate is simple=0A= because it just work with one=0Adevice at the same time.=0A=0AIf you plug = two devices, it will just pick one at random and ignore the=0A other.=0AThe= refore you can not have two devices on the same machine. I don't=0A like th= at.=0ANevertheless you can have more glues (SkypeMate,YahooMate, etc ) on t= he=0A same machine. The user=0Ajust load the specific WHATEVERmate, and whi= chever gets loaded first=0A "owns" the device. =0AIn such a scenario, there= is always one device and one glue, so the=0A choice is trivial. I don't=0A= like that either.=0A=0ANow how are going to manage multiple devices and glu= es without a=0A configuration file ?=0AI can not see any simpler design tha= n:=0A=0A1) The user plugs a device. =0A2) The daemon is automatically launc= hed.=0A3a) If there is just one device and one VoIP program, the specific g= lue=0A is loaded with the device=0Aas a configuration.=0A( a VoIP ping shou= ld be implemented by the glues....)=0A3b) The daemon gets the device's seri= al number and launches/loads the=0A right glue (informing which=0Adevice th= e glue should use) according to the configuration file.=0A=0ANotes:=0A- If = the glue talks to the device thought the deamon, it will talk=0A through a = generic device, with=0Acapabilities.=0A- If the glue talks directly ( and I= can not see a reason for that, the=0A daemon closes )=0A=0ATo make things = simple for the user, a configuration program could be=0A implemented and po= p up=0Awhenever the second device gets plugged. We could have two special= =0A devices called "GLUE DISABLE"=0Aand "ANY DEVICE". Any newly installed g= lue will be by default connected=0A to the "any device"=0Adevice.=0A=0A=0AI= still have not seen/understood anything simpler.... Daniel, your=0A sugges= tion does not handle=0Amultiple glues per device.=0A=0ABy the way, I implem= ented a program called lsYealink, which list the=0A yealink devices. It is = in the=0ASVN. (sf.net/easyb2k) =0AThomas, please upload libyealink to the s= vn, so I can add my code to=0A it.=0A=0A=0AMarcos=0A=0A=0A--- Thomas Reitma= yr <tre...@ya...> schrieb:=0A=0A> Hi,=0A> after reading through the = various emails I missed before, I have a=0A few=0A> comments / suggestions= / thoughts:=0A> =0A> * Using D-BUS instead of UNIX sockets sounds like a g= ood idea. Using=0A> David's drawing the structure would look like=0A> =0A>= VoIP application=0A> ^=0A> | (any protocol, depending = on VoIP application)=0A> v=0A> Glue Software (most likely a separ= ate component, like gnomemeeting=0A> connector)=0A> ^=0A> = | (D-BUS)=0A> v=0A> Our Daemon=0A> =0A> * Also I love the idea = of using HAL, it provides enough information=0A for=0A> the daemon to load= the appropriate low-level device plugin (i.e.=0A> libyealink) and notifie= s the daemon about new or removed devices.=0A The retrieval of the serial= =0A> number (or any other distinctive value) could then be implemented in= =0A the driver plugin.=0A> =0A> Now a question:=0A> You discussed that ther= e could be a "single device" mode (i.e. grab=0A the one device available)= =0A> and a "multi-device" mode, which requires a command-line argument to= =0A the daemon or, if missing,=0A> asks for for it.=0A> Now what I am not 1= 00% understanding in this setup is:=0A> 1. Who starts the daemon, i.e. who = is responsible for supplying the=0A command-line argument?=0A> 2. How can a= user select the right device without diving into the=0A guts of some start= up file?=0A> =0A> What I have in mind would be a daemon which consists of t= he following=0A components:=0A> =0A> a. The daemon core which is only respo= nsible for =0A> - providing the D-BUS object any glue initially connects= to=0A> - tracking available devices via HAL=0A> - dynamically loadin= g the device plugin depending on HAL's device=0A properties=0A> - spawni= ng a daemon device manager (see b.) for a specific device=0A by request of = glue software=0A> - providing a list of available devices by request of = glue=0A software=0A> =0A> b. The daemon device manager, which is instantiat= ed for each device=0A when it is requested by glue=0A> software and which= =0A> - provides the main D-BUS interface for the phone functionality on= =0A one side=0A> - talks to the device plugin on the other side=0A> -= could also implement DTMF or Bell 202 signaling if required by=0A phone (i= mplementation=0A> detail)=0A> - also (via D-BUS) provides information ab= out configuration=0A parameters and methods for=0A> setting/getting these p= arameters (Note: The parameters depend on the=0A selected phone model.)=0A>= =0A> The device plugin(s) could have the following tasks:=0A> - provide a = defined interface to the daemon, including advertising=0A some low-level ca= pabilities=0A> if that makes sense for easier implementation of the daemon = device=0A manager=0A> - provide a unique ID for a specific phone to be pass= ed on all the=0A way up to the glue software=0A> to later identify the phon= e=0A> - implement the low-level USB calls to the device.=0A> =0A> With this= infrastructure the glue software would register with the=0A daemon core an= d if it does=0A> not know about a previously selected specific device, ask = the daemon=0A core for the first=0A> available device. It could also prompt= the user to select one of the=0A available devices. If the=0A> glue softwa= re has found an already selected device ID in its=0A configuration, it coul= d ask for=0A> that specific device only.=0A> >From this point on it would o= nly talk to the newly created daemon=0A device manager about=0A> configurat= ion parameters and then about the general phone operation.=0A> =0A> Did I m= iss KISS?=0A> Is this too complicated, is there a simpler structure allowin= g=0A similar convenience like=0A> SkypeMate?=0A> =0A> Regards,=0A> -Thomas= =0A> =0A> =0A> =0A> Machen Sie Yahoo! zu Ihrer Startseite. Los geht'= s: =0A> http://de.yahoo.com/set=0A> =0A>=0A -------------------------------= ------------------------------------------=0A> This SF.net email is sponsor= ed by: Splunk Inc.=0A> Still grepping through log files to find problems? = Stop.=0A> Now Search log events and configuration files using AJAX and a=0A= browser.=0A> Download your FREE copy of Splunk now >> http://get.splunk.co= m/=0A> _______________________________________________=0A> Easyb2k-devel ma= iling list=0A> Eas...@li...=0A> https://lists.source= forge.net/lists/listinfo/easyb2k-devel=0A> =0A=0A=0A-----------------------= --------------------------------------------------=0AThis SF.net email is s= ponsored by: Splunk Inc.=0AStill grepping through log files to find problem= s? Stop.=0ANow Search log events and configuration files using AJAX and a = browser.=0ADownload your FREE copy of Splunk now >> http://get.splunk.com/= =0A_______________________________________________=0AEasyb2k-devel mailing = list=0AE...@li...=0Ahttps://lists.sourceforge.net/= lists/listinfo/easyb2k-devel=0A=0A=0A=0A=0A=0A Heute schon einen Blick= in die Zukunft von E-Mails wagen? Versuchen Sie=B4s mit dem neuen Yahoo! M= ail. www.yahoo.de/mail |
From: Thomas R. <tre...@ya...> - 2007-10-31 13:38:13
|
Hi,=0AI am not convinced that the daemon should be part of our daemon!=0ATh= e glue software for sure is specific to the VoIP application which provides= its own interface. We _should_ implement the proper glue software for the = most common applications, but there should be the possibility for new or no= t so well-known VoIP apps to access our application. Even if such a VoIP ap= plication would implement our D-BUS interface, the strategy of probing all = _supported_ VoIP apps fails here as every VoIP application would use a diff= erent unique D-BUS object path.=0A=0AIt should be the responsibility of the= glue software _or_ the VoIP app (supporting our D-BUS interface) to probe = the daemon, and in the usual scenario that would be the natural order of th= ings, i.e.=0A1. Daemon core is started at boot time.=0A2. VoIP application = starts (by user or at boot time) and probes the the daemon core.=0A=0ARegar= ds,=0A-Thomas=0A=0A=0A----- Urspr=FCngliche Mail ----=0AVon: Daniel Ribeiro= <dr...@gm...>=0AAn: eas...@li...=0AGesendet: M= ittwoch, den 31. Oktober 2007, 05:58:24 Uhr=0ABetreff: Re: [Easyb2k-devel] = Application Structure=0A=0A-----BEGIN PGP SIGNED MESSAGE-----=0AHash: SHA1= =0A=0AThomas Reitmayr wrote:=0A> But how can the daemon start a certain glu= e software (and maybe the=0A associated VoIP app)? How can one determine ho= w many VoIP apps are=0A installed? And what is a VoIP ping?=0A> Your pt. 3b= looks more practical than 3a but glue software might be=0A part of the VoI= P app and started with it, not by the daemon, couldn't=0A it?=0A Thats w= hy the glue has to be part of our daemon, and not a=0A different=0Aapplicat= ion. We assure that it will only be called at the proper time.=0ATo know ho= w many VoIP apps are running, well.. In the default, *one*=0Adevice case, w= e simply check for all the supported glues, on the=0A*multiple* devices cas= e we load what the user pre-configured on the=0A.conf file.=0A I believe= that what Marcos meant for "ping" is checking if the VoIP=0Aapplication is= running and ready to exchange data.=0A=0A- --=0ADaniel Ribeiro=0A-----BEGI= N PGP SIGNATURE-----=0AVersion: GnuPG v1.4.6 (GNU/Linux)=0A=0AiD8DBQFHKAtww= 3OYl0G0liQRApvhAJ9Qks35l17eb3YEy8ufDAAwmDO/QwCcDZov=0AvwW3unN2SN3BH/hr3mnAb= y0=3D=0A=3D8SMf=0A-----END PGP SIGNATURE-----=0A=0A------------------------= -------------------------------------------------=0AThis SF.net email is sp= onsored by: Splunk Inc.=0AStill grepping through log files to find problems= ? Stop.=0ANow Search log events and configuration files using AJAX and a b= rowser.=0ADownload your FREE copy of Splunk now >> http://get.splunk.com/= =0A_______________________________________________=0AEasyb2k-devel mailing = list=0AE...@li...=0Ahttps://lists.sourceforge.net/= lists/listinfo/easyb2k-devel=0A=0A=0A=0A=0A=0A Machen Sie Yahoo! zu Ih= rer Startseite. Los geht's: =0Ahttp://de.yahoo.com/set |
From: Daniel R. <dr...@gm...> - 2007-10-31 15:06:46
|
2007/10/31, Thomas Reitmayr <tre...@ya...>: > The glue software for sure is specific to the VoIP application which provides its own interface. We _should_ implement the proper glue software for the most common applications, but there should be the possibility for new or not so well-known VoIP apps to access our application. Even if such a VoIP application would implement our D-BUS interface, the strategy of probing all _supported_ VoIP apps fails here as every VoIP application would use a different unique D-BUS object path. > It should be the responsibility of the glue software _or_ the VoIP app (supporting our D-BUS interface) to probe the daemon, and in the usual scenario that would be the natural order of things, i.e. > 1. Daemon core is started at boot time. > 2. VoIP application starts (by user or at boot time) and probes the the daemon core. 2 Will not work with Skype. The main intention of keeping the glue software inside our daemon as a plugin is to keep it _flexible_ enough to support *every* weird protocol that commercial VoIP software may implement. A separate glue software is _unnecessary_, as the VoIP software may implement our protocol directly. the standard use case would be.. Most VoIP applications (active) | v --------------------------- | Standard Glue | | ^ | | | (libdl) | Our Daemon | v | | Core Daemon | ---------------------------- And for Skype.. Skype (passive) ^ | --------------------------- | Special Glue | | ^ | | | (libdl) | Our Daemon | v | | Core Daemon | ---------------------------- -- Daniel Ribeiro |
From: Marcos D. <ma...@un...> - 2007-10-31 15:26:42
|
Let's assume we use Daniel's method... Does that allow the glue to have a GUI ? How will the linking part work ? ( I mean, if a dynamic load a library, does qt/gtk/libGUI gets loaded automatically ? Marcos Daniel Ribeiro wrote: > 2007/10/31, Thomas Reitmayr <tre...@ya...>: >> The glue software for sure is specific to the VoIP application which provides its own interface. We _should_ implement the proper glue software for the most common applications, but there should be the possibility for new or not so well-known VoIP apps to access our application. Even if such a VoIP application would implement our D-BUS interface, the strategy of probing all _supported_ VoIP apps fails here as every VoIP application would use a different unique D-BUS object path. >> It should be the responsibility of the glue software _or_ the VoIP app (supporting our D-BUS interface) to probe the daemon, and in the usual scenario that would be the natural order of things, i.e. >> 1. Daemon core is started at boot time. >> 2. VoIP application starts (by user or at boot time) and probes the the daemon core. > > 2 Will not work with Skype. > > The main intention of keeping the glue software inside our daemon as a > plugin is to keep it _flexible_ enough to support *every* weird > protocol that commercial VoIP software may implement. > A separate glue software is _unnecessary_, as the VoIP software may > implement our protocol directly. > > the standard use case would be.. > > Most VoIP applications (active) > | > v > --------------------------- > | Standard Glue | > | ^ | > | | (libdl) | Our Daemon > | v | > | Core Daemon | > ---------------------------- > > > And for Skype.. > > Skype (passive) > ^ > | > --------------------------- > | Special Glue | > | ^ | > | | (libdl) | Our Daemon > | v | > | Core Daemon | > ---------------------------- > > |
From: Daniel R. <dr...@gm...> - 2007-10-31 15:54:39
|
2007/10/31, Marcos Diez <ma...@un...>: > Does that allow the glue to have a GUI ? Yes, but i dont think that this is a good idea, as it may add latency and instability issues to the core daemon. > How will the linking part work ? ( I mean, if a dynamic load a library, > does qt/gtk/libGUI gets loaded automatically ? Yes, you can load/unload any dynamic lib and it will load other needed dynamic libs linked to the plugin. I believe that the GUI should be a different software, and connect to our daemon using our standard d-bus transport (as other VoIP applications would). -- Daniel Ribeiro |
From: Marcos <ma...@un...> - 2007-10-31 18:00:59
|
Hi! I have BAD BAD news. I found a huge security problem in our model. If we include the glue in the daemon, the glue will be SUID, just as the deamon must be, since it can send direct command to USB devices. So the glue must be a complitelly different process than the daemon, even written by the user. What do you guys think ? Ohhh, what if we call our program TuxMate ? Marcos --- Daniel Ribeiro <dr...@gm...> schrieb: > 2007/10/31, Marcos Diez <ma...@un...>: > > Does that allow the glue to have a GUI ? > Yes, but i dont think that this is a good idea, as it may add latency > and instability issues to the core daemon. > > > How will the linking part work ? ( I mean, if a dynamic load a library, > > does qt/gtk/libGUI gets loaded automatically ? > Yes, you can load/unload any dynamic lib and it will load other needed > dynamic libs linked to the plugin. > > I believe that the GUI should be a different software, and connect to > our daemon using our standard d-bus transport (as other VoIP > applications would). > > -- > Daniel Ribeiro > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Easyb2k-devel mailing list > Eas...@li... > https://lists.sourceforge.net/lists/listinfo/easyb2k-devel > |
From: Daniel R. <dr...@gm...> - 2007-10-31 18:25:10
|
2007/10/31, Marcos <ma...@un...>: > I have BAD BAD news. > I found a huge security problem in our model. Its as simple as dropping privileges right after attaching to the usb port. -- Daniel Ribeiro |
From: Marcos <ma...@un...> - 2007-10-31 18:32:43
|
It is not that simple. We must drop privileges before running user code. So we must drop privileges before loading any glue. So we must attach to the USB port before loading any plugin. So we can not attach to a newly plugged device after any plugin has been loaded. :( --- Daniel Ribeiro <dr...@gm...> schrieb: > 2007/10/31, Marcos <ma...@un...>: > > I have BAD BAD news. > > I found a huge security problem in our model. > Its as simple as dropping privileges right after attaching to the usb port. > > -- > Daniel Ribeiro > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Easyb2k-devel mailing list > Eas...@li... > https://lists.sourceforge.net/lists/listinfo/easyb2k-devel > |
From: Daniel R. <dr...@gm...> - 2007-10-31 18:39:53
|
2007/10/31, Marcos <ma...@un...>: > It is not that simple. > > We must drop privileges before running user code. > So we must drop privileges before loading any glue. > So we must attach to the USB port before loading any plugin. > So we can not attach to a newly plugged device after any plugin has been loaded. You still didnt got the most important point.. _one daemon instance for each device_. 1. The first thing that we will do is attach to the usb port. We need it to get the serial number, so the daemon can decide which .conf file to use and/or which plugins to load. :) 2. When you unplug the device, his controlling daemon exits. 3. When you plug another device, a new daemon is called. Daemon is kind of a bad term. It is more a hotplug loaded driver, and *not* an always running daemon. -- Daniel Ribeiro |
From: Thomas R. <tre...@ya...> - 2007-10-31 13:50:43
|
Hi again,=0Aconfiguring the VoIP application for using the right audio devi= ce is application specific. It should be the responsibility of the glue sof= tware to try to achieve that. If the VoIP app supports it via its proprieta= ry interface which the glue software attaches to, then that's fine and will= be provided by the glue software (eg. in the Skype case, as Marcos told us= ). If it does not, then there is usually a way for the user to configure th= e matching audio devices manually and the glue software does not have to ca= re about it.=0A=0AMost importantly the daemon has to simply offer informati= on about the audio devices to use at the interface to the glue software (by= just looking at the HAL-properties), for Linux that would be the name of t= he ALSA (or OSS, if someone has strong feelings about it) device, for other= OSs probably some other device path.=0A=0ARegards,=0A-Thomas=0A=0A=0A-----= Urspr=FCngliche Mail ----=0AVon: Daniel Ribeiro <dr...@gm...>=0AAn: e= asy...@li...=0AGesendet: Mittwoch, den 31. Oktober 20= 07, 06:49:45 Uhr=0ABetreff: Re: [Easyb2k-devel] Application Structure=0A=0A= My idea is just fine when all that matters is the _control_=0A interfac= e=0Aof the boxes, but we havent discussed how we will configure the VoIP=0A= applications to talk to the right sound device. As the sound codec chip=0Ao= n the telbox devices are handled by alsa in kernelspace this may be=0Atroub= le for future development.=0A ATM we can assure that the control interfa= ce will match the=0A respective=0Aconfiguration based on the box serial num= ber, but i dont know how to=0Aassure that each VoIP application will open t= he correct PCM devices=0Amatching the control interface on the same box.=0A= =0A- --=0ADaniel Ribeiro=0A-----BEGIN PGP SIGNATURE-----=0AVersion: GnuPG v= 1.4.6 (GNU/Linux)=0A=0AiD8DBQFHKBd5w3OYl0G0liQRAhHWAKCCnsYuPcauU/xkjn2Di4K6= XSFA2gCfa0hp=0AKSPCDyXBBSwtT+eSSE8nfQQ=3D=0A=3D/Grm=0A-----END PGP SIGNATUR= E-----=0A=0A---------------------------------------------------------------= ----------=0AThis SF.net email is sponsored by: Splunk Inc.=0AStill greppin= g through log files to find problems? Stop.=0ANow Search log events and co= nfiguration files using AJAX and a browser.=0ADownload your FREE copy of Sp= lunk now >> http://get.splunk.com/=0A______________________________________= _________=0AEasyb2k-devel mailing list=0AE...@li...= t=0Ahttps://lists.sourceforge.net/lists/listinfo/easyb2k-devel=0A=0A=0A=0A= =0A=0A __________________________________ Ihr erstes Baby? Holen Si= e sich Tipps von anderen Eltern. www.yahoo.de/clever |
From: Thomas R. <tre...@ya...> - 2007-10-31 14:18:50
|
Hi,=0AI would not allow the case of having two different devices attach to = one and the same VoIP application. You would have to dynamically adapt the = audio devices in the VoIP app depending on which phone the user picks up.= =0AIf you really need that and you use a regular phone (via B2K or B3K/G) y= ou could attach multiple phones to the same phone line (as Daniel suggested= , I guess). In case of multiple USB handsets you could implement parallel r= inging via a SIP PBX (Asterisk, OpenSER). This does not cover the case of o= ne skype account with multiple handsets though as long as you don't want to= buy a Skype PBX.=0ARegards,=0A-Thomas=0A=0A----- Urspr=FCngliche Mail ----= =0AVon: Marcos Diez <ma...@un...>=0AAn: eas...@li...urc= eforge.net=0AGesendet: Mittwoch, den 31. Oktober 2007, 11:30:06 Uhr=0ABetre= ff: Re: [Easyb2k-devel] Application Structure=0A=0A[...]=0A=0ABy the way, i= f we want to have two different daemons talking to the=0A same =0Askype, th= ey must report different names, or else Skype will go crazy.=0A So =0Athere= must be a configuration option for that.=0A=0ANow if we want to have two d= ifferent Skypes on the same machine, I=0A don't =0Aknow how to do it, becau= se at least XInternAtom(display, =0A"_SKYPE_INSTANCE", 1); returns the fir= st instance if finds.=0AI launched one Skype normally and the other one thr= ough ssh -X =0Auser2@localhost. Does anybody has any better ideas ?=0A=0AMa= ybe DBUS works different.=0A=0AMarcos=0A=0Aps: Daniel, thanks. Now things m= ake sence.=0A=0A-----------------------------------------------------------= --------------=0AThis SF.net email is sponsored by: Splunk Inc.=0AStill gre= pping through log files to find problems? Stop.=0ANow Search log events an= d configuration files using AJAX and a browser.=0ADownload your FREE copy o= f Splunk now >> http://get.splunk.com/=0A__________________________________= _____________=0AEasyb2k-devel mailing list=0AE...@li...urceforg= e.net=0Ahttps://lists.sourceforge.net/lists/listinfo/easyb2k-devel=0A=0A=0A= =0A=0A=0A __________________________________ Ihr erstes Baby? Holen= Sie sich Tipps von anderen Eltern. www.yahoo.de/clever |
From: Daniel R. <dr...@gm...> - 2007-10-31 03:56:50
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thomas Reitmayr wrote: > But how can the daemon start a certain glue software (and maybe the associated VoIP app)? How can one determine how many VoIP apps are installed? And what is a VoIP ping? > Your pt. 3b looks more practical than 3a but glue software might be part of the VoIP app and started with it, not by the daemon, couldn't it? Thats why the glue has to be part of our daemon, and not a different application. We assure that it will only be called at the proper time. To know how many VoIP apps are running, well.. In the default, *one* device case, we simply check for all the supported glues, on the *multiple* devices case we load what the user pre-configured on the .conf file. I believe that what Marcos meant for "ping" is checking if the VoIP application is running and ready to exchange data. - -- Daniel Ribeiro -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHKAtww3OYl0G0liQRApvhAJ9Qks35l17eb3YEy8ufDAAwmDO/QwCcDZov vwW3unN2SN3BH/hr3mnAby0= =8SMf -----END PGP SIGNATURE----- |