Suggestion to the SuSE security people
Hi there, I have a suggestion to you security guys, that could make life a lot easier for a lot of us out here, and at the same time really make the SuSE security update feature shine, compared to the other linux distributions. I have noticed that since 24/9-00 six updates to SuSE 7.0 has been posted on your security site. At this rate it could turn out to be a very time consuming job having to update Linux all the time. To make this a much easier task, I suggest that you, on top of the usual downloadable update files, make available a gzip file containing all the updates relevant to your latest distribution (7.0 at this moment). Every time a new update is posted you also post a new gzip file that includes all earlier updates AND the new one. This file could be called SU1, SU2... SUn. (SU = Security Update). The gzip file should, besides the .rpm files, include a shell script that could automate all the updates. The script could maybe do something like this: for (first_update to last_update present in the gzip file) do { if (module or program that the updated relates to is installed on the target system) { do_update = false if (this update is older then the one installed) do_update = ask_user_if_ok_to_update () else if (module has not been updated) { if (running update will overwrite config file(s) that the user/system may have edited) { if (do_update = ask_user_if_ok_to_update ()) make copy (.bak) of config file(s) } } if (do_update) run the rmp update } else do_nothing } A procedure like this could really make a difference. Updating could now be almost totally automated, and if SuSE would post an e-mail to this forum when a new update is released, I'm sure a lot of SuSE installations would be updated much more frequently then is the case today. I for one would update our systems a lot more frequently. Lets also say that you put a subject string like "Announce: SuSE security update SU05 is released ...." in the e-mail, and in the Message body a link to the newest update file. Users could then make a filter in their e-mail client that would redirect all mail coming from SuSE containing this subject string, to a high priority mailbox. When the user opens the mail, he just clicks on the link and this baby would rock'n role. Of cause I could write the script my self, but that would not make the downloading easier at all, and here I see a opportunity for SuSE, with very little effort, to really make thinks much more "user friendly". Thanks in advance Bo Jacobsen bjc@image.dk
Or you could just install autorpm or something similar. http://www.securityportal.com/lskb/10000050/kben10000077.html Personally I think your idea has merit, but it's way to ugly/crude. What I would like to see is SuSE doing something like Red Hat's network program, they'll be handling updates/etc/etc for people for a minimal cost. Ideally vendors should harass users to sign up on a security announcement mailing list during install, and post easy to read/understand advisories with exact instrcutions for update install (and run a sufficiently powerful ftp server to house all the updates). Also be nice if there was something nice and simple like windows update, go to a website, run a local thing to list what you got, remote site tells you what you need/etc. In any event all the vendors have a ton of work to do making updates easier for end users. Kurt Seifried - seifried@securityportal.com SecurityPortal, your focal point for security on the net. http://www.securityportal.com/
Em Wed, Oct 04, 2000 at 03:09:12AM -0600, Kurt Seifried escreveu:
to house all the updates). Also be nice if there was something nice and simple like windows update, go to a website, run a local thing to list what you got, remote site tells you what you need/etc. In any event all the vendors have a ton of work to do making updates easier for end users.
apt-get is being patched to support RPM packages as well, and with GPG support: [root@pandora /root]# apt-get update Get:1 http://zaphod.distro.conectiva latest/conectiva/base/hashfile [176B] Fetched 1B in 0s (2B/s) Hit http://zaphod.distro.conectiva latest/conectiva/base/pkglist.001 Ign http://zaphod.distro.conectiva latest/conectiva release Get:1 ftp://mapi2.distro.conectiva 5.9/conectiva/base/pkglist.001 [887kB] Get:2 ftp://mapi2.distro.conectiva 5.9/conectiva release Ign ftp://mapi2.distro.conectiva 5.9/conectiva release Get:3 ftp://mapi2.distro.conectiva 5.9/conectiva/base/pkglist.002 [472kB] Fetched 1360kB in 0s (1847kB/s) Processing File Dependencies... Done Reading Package Lists... Done Building Dependency Tree... Done [root@pandora /root]# LC_ALL= LANG= apt-get upgrade Processing File Dependencies... Done Reading Package Lists... Done Building Dependency Tree... Done The following packages have been kept back gnome-core gnome-libs perl-Digest-MD5 perl-MD5 reiserfs-utils The following packages will be upgraded Gtk-Perl Gtk-Perl-GdkImlib XFree86 XFree86-100dpi-fonts XFree86-75dpi-fonts XFree86-Server XFree86-Xnest XFree86-Xvfb XFree86-cyrillic-fonts XFree86-devel XFree86-doc XFree86-libs XFree86-xfs anonftp apache-devel apache-doc bzip2 bzip2-devel dev fileutils flying fvwm2-extras gettext-tupdate gfcc ghostscript ghostscript-fonts glibc glibc-devel glibc-profile gmc gmp gnome-core-devel gnome-libs-devel howto howto-html howto-portuguese howto-sgml howto-spanish info initscripts kudzu kudzu-devel librep librep-devel mc mcserv mon-perl mutt mxp nc ncompress nscd p2c p2c-devel perl-DBI perl-HTML-Parser perl-MIME-Base64 perl-Period perl-Time-HiRes perl-gettext pinfo postgresql-clients postgresql-clients-X11 postgresql-devel postgresql-doc postgresql-jdbc postgresql-lib postgresql-odbc postgresql-perl postgresql-tcl ppp python python-devel python-doc python-idle rep-gtk rep-gtk-gnome sawfish sendmail sendmail-cf sendmail-doc sharutils squid sxid texinfo tkinter ucd-snmp-utils vim-X11 vim-common vim-enhanced vim-help vim-minimal vim-syntax webxref wine wine-devel wine-doc x3270 xbill xpilot 100 packages upgraded, 0 newly installed, 0 to remove and 5 not upgraded. Need to get 128MB of archives. After unpacking 214kB will be used. Do you want to continue? [Y/n] oops, lots of new packages, these betas move too fast... :-) -- Andreas Hasenack andreas@conectiva.com.br BIG Linux user!
Hi, to Kurt:security and endusers do not fit well together. To keep a system somewhat secure you need to know your system, making updates as described by you will lead to more unsecure systems in the end as endusers will no longer call a technician but do it themselves without knowing whether or not their systes are secure anyway. In general there are different security needs, and allways updating a complete set of all known vulnerabities is defenitely a waste of bandwidth. Why update sendmail when using qmail, or wuftpd when using proftpd, .... What I wanted to see (I know that will be absolutely irrelevant for most) was an "I" od "X" flag to announcements, preferred in the subject, indicating an vulnerabity to attacks from internal or external source. (I do not care about vulnerabities from internal users, either for the lock of them or their lack of knowledge) mike
Hi,
[snipsnip]
What I wanted to see (I know that will be absolutely irrelevant for most) was an "I" od "X" flag to announcements, preferred in the subject, indicating an vulnerabity to attacks from internal or external source. (I do not care about vulnerabities from internal users, either for the lock of them or their lack of knowledge)
Most advisories usually classify the threat (internal, external, needs an account or not). This is actually something SecurityPortal is working on, since we sell information/etc. I've tried to get people interested in this (wrote an article on writing security advisories): http://www.securityportal.com/closet/closet20000913.html I'm not sure having it in the subject line of the email is needed, but it definetely should be in the advisory somewhere near the top.
mike
-Kurt
Hi, On 05-Oct-00 Thomas Michael Wanka wrote:
Hi,
to Kurt:security and endusers do not fit well together. To keep a system somewhat secure you need to know your system, making updates as described by you will lead to more unsecure systems in the end as endusers will no longer call a technician but do it themselves without knowing whether or not their systes are secure anyway. In general there are different security needs, and allways updating a complete set of all known vulnerabities is defenitely a waste of bandwidth. Why update sendmail when using qmail, or wuftpd when using proftpd, ....
Totally agreed. Mass updates in Microsoft style where one has to download some 100 MBs of service packs is nonsense. From a security admin's view it is nonsense, too, to upgrade packages just because there's a new version out; if you don't need the new features or if there are no serious bugfixes or plugged security holes, updating is just a (possibly dangerous) waste of time.
What I wanted to see (I know that will be absolutely irrelevant for most) was an "I" od "X" flag to announcements, preferred in the subject, indicating an vulnerabity to attacks from internal or external source. (I do not care about vulnerabities from internal users, either for the lock of them or their lack of knowledge)
I am not convinced that such flags would be a good idea. It may lead people to think that their systems without shell accounts (but with smtp, pop3 and/or ssh) are perfectly safe if they keep their "external" packages up to date. If their freshly updated wuftpd turns out to be buggy, black hats may gain access and happily root the machine by exploiting "internal" packages and their occasional vulnerabilities which have never been fixed properly. Personally I do not trust anyone interacting with my hosts, even less if it is an internal user. According to my experiences there's a percentage of 10 to 20% of security breaches committed by internal or "trusted" users; "the enemy lies within"! ;-) Boris ---
Totally agreed. Mass updates in Microsoft style where one has to download some 100 MBs of service packs is nonsense. From a security admin's view it is nonsense, too, to upgrade packages just because there's a new version out; if you don't need the new features or if there are no serious bugfixes or plugged security holes, updating is just a (possibly dangerous) waste of time. [snipsnip] I am not convinced that such flags would be a good idea. It may lead people to think that their systems without shell accounts (but with smtp, pop3 and/or ssh) are perfectly safe if they keep their "external" packages up to date. If their freshly updated wuftpd turns out to be buggy, black hats may gain access and happily root the machine by exploiting "internal" packages and their occasional vulnerabilities which have never been fixed properly.
Personally I do not trust anyone interacting with my hosts, even less if it is an internal user. According to my experiences there's a percentage of 10 to 20% of security breaches committed by internal or "trusted" users; "the enemy
Also there are many problems (like in POP, ftp for example) where a user account is required to exploit it, making it an "internal" threat. There is a huge difference between an anonymous ftp exploit, and one requiring a user account. lies
within"! ;-)
You will find that as your perimeter security gets better (firewalls, anti virus, intrusion detection, etc.) the percentage of attacks originating from within will grow =). I'm just gonna quote an article I'm writing cause I'm lazy Security is a holistic practice, you can't just plug one hole and expect all your problems to be solved. No matter how perfect a technological solution you use (encryption, firewalls, etc.) as long as there are humans involved mistakes can be made, and people you thought you could trust turn out to be hostile in intent.
Boris
-Kurt
Personally I do not trust anyone interacting with my hosts, even less if it is an internal user. According to my experiences there's a percentage of 10 to 20% of security breaches committed by internal or "trusted" users; "the enemy
Hi2all, lies
within"! ;-)
For those who are interested in this kind of numbers, at least by the CSI/FBI Survey on cybercrime, in 2000 respondents to this survey reported: 71% detected unauthorized access by insiders (1997-40%;1998-44%;1999-55%) 79% detected employee abuse of internet access privileges (1997-68%;1998-77%;1999-97%) According to this survey, the likely sources of attack, regarding insiders are close to 85% average in the last 4 years. So the enemy lies within more then many people could supposed. Regarding the several suggestions to SuSe sec team, i agree that upgrades/fixes must not be available in Microsoft style (for that we allready got Microsoft, right? eheheh). About "I" and "X" flags, if they could be usefull to some of us, well, why not use them ... who dont care about that, or that makes no diference, there is no harm done i suppose (personally i'll ignore those flags, intruders are intruders where ever they are). About "auto_whatever" i leave that to my windoze boxes, for linux i want to know exactly what happend and what is installed/fixed. It is like somebody said, if something is working ok and new features are just a waste of time, i hope no "auto" can mess with that. But again, if the "auto" exists, just let people choose between that and the old fashion way, and all got their wanted solution. One time somebody here also had refered the gap of info about the need of rebooting after an upgrade. That can be very usefull since there are people who use this as server (and reboots can't be done at all time, for example just at night or at weekends), while others (like me) use suse more as a workstation, or a off-line server for tests only, so i can reboot any time i like but others cant. And at last, don't forget a suggestion i had made once ... share with us some info about security tests that SuSe sec team make regarding specific tools/architectures, it can be usefull to several of us, and avoid the need of getting that info by other means, or wasting time in tests allready done by others, or compare those tests with other tests. Finished the suggestions ... guys we also must give some congratulations to SuSe sec team, since version 7.0 (that FINALLY i got a copy eheh) have some improvements (not just fixes and new versions of packages), some very important to the enduser, like the diferences that there are now between the 'root' desktop and the 'user' desktop under KDE. Like, after the 1st installation (without reading anything like any good enduser does eheheh) i just wondered where the hell some icons had gone? What i did wrong? anything eheh was just that some things are diferent now =;o) [ ]'s bacano p.s. - finally i was able to use yast2 on my laptop without having video problems ... thanks a lot p.s.2 - thanks also for including quanta on the distribution, next time dont forget Morphon editor :P~
On Thu, 5 Oct 2000, bacano wrote:
About "auto_whatever" i leave that to my windoze boxes, for linux i want to know exactly what happend and what is installed/fixed. It is like somebody said, if something is working ok and new features are just a waste of time, i hope no "auto" can mess with that. But again, if the "auto" exists, just let people choose between that and the old fashion way, and all got their wanted solution. Maybe some semi-auto-thing would be best. I have several servers at several places to keep up-to-date and what I _really_ want is to know if I'm up-to-date on every server. (Because sometimes one is unreachable or i just forget). so this auto-check should look for new packages and give me the offer to upgrade (interactive or per mail notification, when run as a cron-job), so I know, that something is to do (or not) I haven't checked autorpm by now, maybe it's just what I want :)
bye Markus -- _____________________________ Markus Gaugusch ICQ 11374583 markus@gaugusch.dhs.org 118
It's quite hard to get the balance right between making it as easy as possible for administrators (who may well not be experts) to keep up-to-date with security fixes while avoiding the risk of damaging the system by an over-enthusiastic application of updates. One essential pre-requisite is that it must be possible for a utility to distinguish between security updates and non-security updates; I'm not sure if this is possible at present. And the suggestion about distinguishing between external and internal threats is also a good one. Given this it would be possible for autorpm (or something like it) to ignore most updates and only apply (or offer to apply) security fixes. Bob ============================================================== Bob Vickers R.Vickers@dcs.rhbnc.ac.uk Dept of Computer Science, Royal Holloway, University of London WWW: http://www.cs.rhbnc.ac.uk/home/bobv Phone: +44 1784 443691
It's quite hard to get the balance right between making it as easy as possible for administrators (who may well not be experts) to keep up-to-date with security fixes while avoiding the risk of damaging the system by an over-enthusiastic application of updates.
One essential pre-requisite is that it must be possible for a utility to distinguish between security updates and non-security updates; I'm not sure if this is possible at present. And the suggestion about distinguishing between external and internal threats is also a good one.
Given this it would be possible for autorpm (or something like it) to ignore most updates and only apply (or offer to apply) security fixes.
A painfully simple solution comes to mind =). TurboLinux has directories on their ftp site for security updates... Just point your autorpm or whatever at them and tada. You only get security updates.
Bob
Kurt Seifried - seifried@securityportal.com SecurityPortal, your focal point for security on the net http://www.securityportal.com/
A painfully simple solution comes to mind =). TurboLinux has directories on their ftp site for security updates... Just point your autorpm or whatever at them and tada. You only get security updates.
We're doing that, too, already (there's even a more fine tuned approach). It's just not visible yet, because it's still being tested. But expect the directories soon.
Kurt Seifried - seifried@securityportal.com
Thanks,
Roman.
--
- -
| Roman Drahtmüller
Where can I sign up to be a beta-tester? >;) Please, PLEASE keep us (me, at least) up to date on this. Thanks, Geordon At 07:49 AM 10/5/00, Roman Drahtmueller wrote:
A painfully simple solution comes to mind =). TurboLinux has directories on their ftp site for security updates... Just point your autorpm or whatever at them and tada. You only get security updates.
We're doing that, too, already (there's even a more fine tuned approach). It's just not visible yet, because it's still being tested.
But expect the directories soon.
Kurt Seifried - seifried@securityportal.com
Thanks, Roman. -- - - | Roman Drahtmüller
// "Caution: Cape does | SuSE GmbH - Security Phone: // not enable user to fly." | Nürnberg, Germany +49-911-740530 // (Batman Costume warning label) | - - --------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
Where can I sign up to be a beta-tester? >;)
Please, PLEASE keep us (me, at least) up to date on this.
Thanks, Geordon
1) It is planned for the future.
2) The details are not set yet.
3) There will not be a "beta" program - if that stuff doesn't work, we
don't ship it. Period.
4) Package signing is an intrinsic value of such a system.
5) Resource issues will have to be resolved before the system starts.
6) Of course, this list will be the first to read about it.
7) The directory with symlinks to security updates is independent from
some (semi-)automatic update mechanisms. This may not be valid the
other way around.
7) These format string parsing bugs are giving us a hard time these
days. We can concentrate on update facilities as soon as the most
urgent problems are out of our way.
Thanks,
Roman.
--
- -
| Roman Drahtmüller
Thanks, Roman. Whoever complains that SuSE support isn't helpful can just get stuffed, IMHO. :) To comment on a couple of things that you said... At 08:14 AM 10/5/00, Roman Drahtmueller wrote:
Where can I sign up to be a beta-tester? >;)
Please, PLEASE keep us (me, at least) up to date on this.
Thanks, Geordon
1) It is planned for the future.
Is there any sort of estimated time-line for release, or is it too early for that?
2) The details are not set yet. 3) There will not be a "beta" program - if that stuff doesn't work, we don't ship it. Period.
<sarcasm> Why would you want to make sure that your products are working before they get to the public? After all, isn't that what initial release is for, to let the public find and fix the bugs, so that you don't have to pay developers? </sarcasm> Thank you! After the fiasco that I had when going from RedHat 5.2 to 6.0 and the upgrade breaking EVERYTHING on my system... That and the fact that I like to know that things are going to work as designed in the FIRST place are tremendous assets. I'll skip the "public beta" if the result is a correctly functioning product at release time.
4) Package signing is an intrinsic value of such a system.
Where can I get the appropriate key? Are you going to use PGP/GPG for signing?
5) Resource issues will have to be resolved before the system starts.
<humour> Gee, it sounds like you folks are thinking ahead. Why would you do that? It's an awful lot like good customer service! </humour>
6) Of course, this list will be the first to read about it.
Thank you, thank you, danke!
7) The directory with symlinks to security updates is independent from some (semi-)automatic update mechanisms. This may not be valid the other way around.
I'm a little confused about this... However, I'm sure that all will become clear as time goes on.
7) These format string parsing bugs are giving us a hard time these days. We can concentrate on update facilities as soon as the most urgent problems are out of our way.
Shame on you! Focusing on the highest priority problems first! That's not on the "approved list of ways to run a business" that Micro~1 put out... ;)
Thanks, Roman.
I for one appreciate it. Thank YOU , Roman and the rest of the SuSE folks here!
Is there any sort of estimated time-line for release, or is it too early for that?
No not yet. If we announced something, we'd have to keep to it. Personally, I like surprises better than vapor ware. For now, "we just think about it".
<sarcasm> Why would you want to make sure that your products are working before they get to the public? After all, isn't that what initial release is for, to let the public find and fix the bugs, so that you don't have to pay developers? </sarcasm>
I don't dare to smile on that right now. [...]
4) Package signing is an intrinsic value of such a system.
Where can I get the appropriate key? Are you going to use PGP/GPG for signing?
Will be on the CDs. And on the web.
[...] (thanks!)
It can't be all wrong if it's fun to do it and it promises to stay like
this in the future. ("Have a lot...")
Thank you.
Roman.
--
- -
| Roman Drahtmüller
At 08:36 AM 10/5/00 -0500, you wrote:
Thank you! After the fiasco that I had when going from RedHat 5.2 to 6.0 and the upgrade breaking EVERYTHING on my system... That and the fact that I like to know that things are going to work as designed in the FIRST place are tremendous assets. I'll skip the "public beta" if the result is a correctly functioning product at release time.
Ok if I am reading this message correctly... Geordon who every the heck you are get stuffed.... You only switched to SuSE after Myself and another Gent twisted your arm and put your fingers up your but! :> Now at least you publicly state you like SuSE better... Enjoy! Sorry I skipped out of the office on Friday before you got it. But I need some work to do, at least I have it at home. --Leif Gotta love that on call type of work. But hey once they go solaris 8 from 2.5.1 maybe I will have some real work to do.
Yah, Leif, you Norweigian nut-case... You seem to have forgotten that I went from RH *back* to Slackware... Heck, at this point, I'm starting to think that you'd prefer Windows 3.11! ;) I never said that I didn't like SuSE... Only that I'd never tried it. Far be it for me to deny that there was (is) a better product on the market! Besides, whose copy of 7.0 Pro did you borrow, hum? I'll see you in the office some time next week, maybe. Geordon At 03:20 PM 10/7/00, Leif Ericksen wrote:
Ok if I am reading this message correctly... Geordon who every the heck you are get stuffed.... You only switched to SuSE after Myself and another Gent twisted your arm and put your fingers up your but! :>
Now at least you publicly state you like SuSE better...
All prayers are answered. However, sometimes the answer is "No."
ditto... cmon roman.. i think most ppl on this list would be only too happy to help out with testing something that will improve their favorite operating system. Thats what open source is all about, even if we are not all excellent programmers we CAN help with things like this.. Cheers Nix At 09:00 PM 5/10/2000, you wrote:
Where can I sign up to be a beta-tester? >;)
Please, PLEASE keep us (me, at least) up to date on this.
Thanks, Geordon
At 07:49 AM 10/5/00, Roman Drahtmueller wrote:
A painfully simple solution comes to mind =). TurboLinux has
directories on
their ftp site for security updates... Just point your autorpm or whatever at them and tada. You only get security updates.
We're doing that, too, already (there's even a more fine tuned approach). It's just not visible yet, because it's still being tested.
But expect the directories soon.
Kurt Seifried - seifried@securityportal.com
Thanks, Roman. -- - - | Roman Drahtmüller
// "Caution: Cape does | SuSE GmbH - Security Phone: // not enable user to fly." | Nürnberg, Germany +49-911-740530 // (Batman Costume warning label) | - - --------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
Hi!
Hi there, I have a suggestion to you security guys, that could make life a lot easier for a lot of us out here, and at the same time really make the SuSE security update feature shine, compared to the other linux distributions.
Thank you for the contribution. Please allow me to comment on your suggestions.
I have noticed that since 24/9-00 six updates to SuSE 7.0 has been posted on your security site. At this rate it could turn out to be a very time consuming job having to update Linux all the time.
It is! Even more problematic is the outlook: We'll have to expect more of these format string parsing errors in the next few months.
To make this a much easier task, I suggest that you, on top of the usual downloadable update files, make available a gzip file containing all the updates relevant to your latest distribution (7.0 at this moment).
Well... $ du -ks update/7.0 170819 7.0 $ I'm not sure that you really want that... It's just not practicable.
Every time a new update is posted you also post a new gzip file that includes all earlier updates AND the new one. This file could be called SU1, SU2... SUn. (SU = Security Update).
The gzip file should, besides the .rpm files, include a shell script that could automate all the updates. The script could maybe do something like this:
for (first_update to last_update present in the gzip file) do { if (module or program that the updated relates to is installed on the target system) { do_update = false if (this update is older then the one installed) do_update = ask_user_if_ok_to_update () else if (module has not been updated) { if (running update will overwrite config file(s) that the user/system may have edited) { if (do_update = ask_user_if_ok_to_update ()) make copy (.bak) of config file(s) } } if (do_update) run the rmp update } else do_nothing }
A solution like this exists already. One of the replies to your mail contains a hint to it.
A procedure like this could really make a difference. Updating could now be almost totally automated, and if SuSE would post an e-mail to this forum when a new update is released, I'm sure a lot of SuSE installations would be updated much more frequently then is the case today. I for one would update our systems a lot more frequently.
No question...
Lets also say that you put a subject string like "Announce: SuSE security update SU05 is released ...." in the e-mail, and in the Message body a link to the newest update file. Users could then make a filter in their e-mail client that would redirect all mail coming from SuSE containing this subject string, to a high priority mailbox. When the user opens the mail, he just clicks on the link and this baby would rock'n role.
Of cause I could write the script my self, but that would not make the downloading easier at all, and here I see a opportunity for SuSE, with very little effort, to really make thinks much more "user friendly".
We're working on that, of course. One of the features for the future is that our packages will be gpg-signed. Without this feature we would never be able to offer something like an automatic or semi-automatic update machanism. It just knocks out the concept of security in general...
Thanks in advance Bo Jacobsen bjc@image.dk
Thanks,
Roman.
--
- -
| Roman Drahtmüller
participants (12)
-
Andreas Hasenack
-
bacano
-
Bo Jacobsen
-
Bob Vickers
-
bolo@lupa.de
-
Geordon VanTassle
-
Kurt Seifried
-
Leif Ericksen
-
Markus Gaugusch
-
Nix
-
Roman Drahtmueller
-
Thomas Michael Wanka