Re: Reforming 'orig.tar.gz' with included tar-ball.
Mats Erik Andersson wrote: Is there some reverence that should prevent me from taking the step of letting a new 'orig.tar.gz' be a byte-for-byte copy of the upstream source archive? I will make the new package conform to 3.0 (quilt). It's nothing wrong and even preferable to convert your package to 3.0 format. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: ripit (updated package)
Elimar Riesebieter wrote: I am looking for a sponsor for the new version 3.8.2-1 of my package ripit. As far as i see it breaks DPM 2.2.1 by depending on non-free (and even not-existant in Debian) packages. Would you get rid of these dependencies and only Suggest them? Please, use DEP-3 patch headers. You may ask me then to upload it. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: What to do if the original tarball contains a debian subdirectory
Dmitrijs Ledkovs wrote: I have a similar question. Upstream has file ./debian/files in their tarball. Lintian complained about that file so I've deleted it. But during build in pbuilder it gets added back from the orig tarball. How to handle this? That's because such change cannot be represented in diff. Instead, you may want to truncate the upstream debian/files. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: What to do if the original tarball contains a debian subdirectory
Luca Niccoli wrote: The original tarball already contains a debian subdirectory (which needs some corrections anyway), how should I deal with that? If I dh_make straight after unpacking the tarball, dh_make won't modify the debian subdirectory; but I wonder if removing it beforehand will tamper the orig.tar.gz It's nothing wrong to make changes in ustream's /debian directory wich will be represented in diff -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [Bulk] Re: Advice about first package building (from sources)
Laurent Guignard wrote: I'll build a chroot environment with deboostrap with unstable. I'll have to build the new libnet1 package of David Paleino from all files he upload on mentors.debian.net (with Debian unstable dependencies). After, I'll can build my package from source. It seems to be the better solution... My words clean and stable means that I have a Debian stable and i doesn't want to upgrade to testing or unstable, so i need a specific environment to build package. No, you do not! You need what you already have - the Debian Etch environment. You can, of course make `debootstrap etch` in trying to not pollute your clean 'working' environment with build dependencies, or whatever, but this is not necessary. OTOH, if you build your binary package in Debian Sid enviroment, they could be suitable for Sid (that's the point!), but you have a little chance to install them in Etch due to broken dependecies. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Advice about first package building (from sources)
Laurent Guignard wrote: I have read the main documentation about pbuilder but i haven't seen if it is possible to build a package from upstream sources. In all examples, the command is like pbuilder build ???.dsc What is the correct method to build a package from upstream sources ? I thought to build a virtual host (KVM), install all packages needed, import all sources (upstream with all files needed to build package) and run the dpkg-buildpackage command... All this to keep a clean and stable Debian on my laptop ;) Is there another method and where can i found documentation ? You do not need pbuilder for your purposes, not even chroots. What you need is to *create* Debian source package using upstream sources. Read more at http://www.debian.org/doc/maint-guide/ Then, you could build and install the binary package you wanted in your own clean and stable Debian environment. After that, you can safely remove all build dependencies. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#461513: cdbs: requires aclocal.m4 to be present in order to generate it
Hi there! I admit that in my case it is a cornercase: it is an old package that necessitates the autotools to be ran again with newer versions in order to build. I do this with the DEB_AUTO_UPDATE* variables of CDBS. I placed a fake aclocal.m4 to force DEB_AUTO_UPDATE_ACLOCAL=1.10 to take effect. All of this comes of course from the fact that the package seems abandonned upstream. Actually, for other reasons I ended up thinking that it is not suitable for Debian unless somebody revives it upstream. This discussion and also the CDBS documentation CDBS can be asked to update Autoconf, Automake, and Libtool generated files, but this behavior is likely to break the build system and is strongly discouraged make me feel than a piece of source code i've got suffers of something not clearly understandable by me. (It have a bootstrap.sh file which runs autoheader aclocal automake --foreign --add-missing autoconf and of course no aclocal.m4). Could you point me to an explanation of what is wrong with such kind of source code? Why it's considered to be so complex for a package build system. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdbs: how to move file after install target?
Jack Bates wrote: install:: mv -i $(DEB_DESTDIR)/usr/bin/scripts/phpcs-svn-pre-commit $(DEB_DESTDIR)/usr/share/subversion/hook-scripts/phpcs - but it has no effect: The script is still installed at /usr/bin/scrips/phpcs-svn-pre-commit It is unclear from your post, does your `mv' actually invoked? If it doesn't, then probably you wrote your install rule *after* buildcore.mk inclusion. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: deb/debian suffixes in packages
Eugene V. Lyubimkin wrote: Thank you for answer. May be, it's reasonable to add this info (after formatting) to devreference? I believe it's not a policy but a somewhat common used practice. You are free to use *any* revision suffixes in your packages because revisions itself have only one (pure technical) meaning: they are one part of vesrion numbering scheme. Not more, not less. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: deb/debian suffixes in packages
Eugene V. Lyubimkin wrote: Shouldn't devreference describe common used practices? It's not a policy, after all. OTOH, devreference is not a collection of common used practices (what is may be sad), but a overview of the recommended procedures and the available resources IMHO, whict is more suitable for such things inclusion into is Debian Wiki. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Query about Debian
Ambareen! Since this is mentor's list, not user's, i'll try to explain you what you're doing wrong from a Debian developer's point of view. What you do want actually is to have a _stable_ OS. So please use Etch in your source.list. If you just considering to start mixing you own system with testing or unstable, please reconsider again: you should know what you doing. For the purpose of package buildings for Sid use another methods such as pbuilder. In any case, do it in _another_ environment: chroot, User Mode Linux etc. -- Regards, Al Nikolov jid: [EMAIL PROTECTED] irc: clown uin: 312108671 pgp fingerprint: 4B50 F1E3 080C 21A2 91F4 8BF0 CD60 3B5A 2ECF 984B -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Unused libraries copyrigths
Hello, mentors! In a case when upstream tarball contains some third party libraries which are not used in favor to theirs packaged versions, what should be done? 1. Third party code should be stripped off from orig.tar in source package. or 2a. It still there, but nothing about it's copyright should be declared in the copyright file. or 2b. All copyrights should be declared though the third party code is not used in binary package (just because it is distributed in source package). -- Regards, Al Nikolov jid: [EMAIL PROTECTED] irc: clown uin: 312108671 pgp fingerprint: 4B50 F1E3 080C 21A2 91F4 8BF0 CD60 3B5A 2ECF 984B -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
inactive maintenance
Hello, mentors I'm wondering if there is a practice to force package to be orphaned in a case of chronic lack of maintenance? Perhaps, for some package there was no maintainer activity for several years, but only NMU's, wich purpose was not to fix some critical bugs but just to update a very old software version. The situation is even worse: the maintainer is popping up from time to time and permitting to do a NMU with so much changes in the package. In result, there is possible to upload to 'experimental' keeping all old technical garbage and crooks and not to improve the packaging quality. Should exist some way to fix that. -- Regards, Al Nikolov jid: [EMAIL PROTECTED] irc: clown uin: 312108671 pgp fingerprint: 4B50 F1E3 080C 21A2 91F4 8BF0 CD60 3B5A 2ECF 984B -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
dsc: Format
Hi, there! Any meaning of this? The value of 1.0 is hardcoded in dpkg-source (lenny/sid). The current Policy claims: The most current format described in the Policy Manual is version 1.5. -- Regards, Al Nikolov jid: [EMAIL PROTECTED] irc: clown uin: 312108671 pgp fingerprint: 4B50 F1E3 080C 21A2 91F4 8BF0 CD60 3B5A 2ECF 984B -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
main or contrib?
Hello, all mentors! Please clarify for me, in which section should go a GPL-licensed package, which is quite unusable without (but technically not Depends on), er, obscure blobs of data, usually gathered by a way of sniffing data flow between a proprietary application and a hardware device, and then just repeated as is? I'm interested in a package named eciadsl: Package: eciadsl Priority: extra Section: net Installed-Size: 300 Maintainer: Marco d'Itri [EMAIL PROTECTED] Architecture: i386 Version: 0.10-1 Depends: libc6 (= 2.3.2.ds1-4) Recommends: ppp (= 2.4.2+20031002-3), hotplug Filename: pool/main/e/eciadsl/eciadsl_0.10-1_i386.deb Size: 137476 MD5sum: aefea4baeafe774bfa5ec792a8ece8bc SHA1: 250b3c357ad09f2dfbe53d21aa53b97700e61372 SHA256: e898c2642af6975be63428215636b0c7850e7a72f1c4273a07b4d23d72945c47 Description: userspace driver for the Globespan-based USB ADSL modems This package contains userspace utilities and daemons necessary to get working in Linux the USB ADSL modems based on the Globespan chipset. It requires so called synch file, which fits your ADSL provider, and load it to your modem during initialization process. A bunch of ready to use synch files is available for no cost from the eciadsl upstream (http://eciadsl.flashtux.org/download.php), but not included in eciadsl package. Seems like all that synch data was sniffed from USB under Windows and proprietary device driver. To me, this package should be moved from main to contrib. -- Regards, Al Nikolov jid: [EMAIL PROTECTED] irc: clown uin: 312108671 pgp fingerprint: 4B50 F1E3 080C 21A2 91F4 8BF0 CD60 3B5A 2ECF 984B -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: proxycheck -- link
отправлено в группы и по почте Christoph Haas wrote: Found it. Checked it. Uploaded it. Thank you. Minor thoughts on the package: - Please don't change past entries in the changelog even though I understand that you wanted to correct the line wrapping. Yes, i understand such the necessity. - Consider using dpatch for changing the upstream sources. You may find it easier to keep or remove patches when the next upstream version is released. Thanks, probably i should realize the dpatch's advantage. Is there any article about it? - I assume you have sent your patches upstream already. I did. -- Regards, Al Nikolov JID [EMAIL PROTECTED]IRC clown UIN 312108671 PGP 4B50 F1E3 080C 21A2 91F4 8BF0 CD60 3B5A 2ECF 984B -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: dsbltesters
отправлено в группы и по почте Christoph Haas wrote: - Please close the WNPP bug 273204 which you opened yourself one and a half year ago. Ok, i'll close it. I assumed though that ITP should be closed after that the package was become ready and was appeared in the pool. I'm i wrong? Please use the debian/changelog to close it. http://www.de.debian.org/doc/manuals/developers-reference/ch-pkgs.en.html#s-upload-bugfix Yes, that's better. - The copyright file should contain the years of copyright. Ok, i'll fix that. BTW i see many copyright files in Debian packages whitout (c)year lines. Is it actually a violation? http://groups.google.de/group/linux.debian.announce.devel/browse_frm/thread/ee00935883c7bec2/5326ec35388edb3c IMHO, the Debian Policy really should be more exacting. - There has been long time no change. Did you contact the upstream to make sure the software is still maintained? This piece of software is developed and distributed by dsbl.org project which acts as great free network service. I have no doubt, the software is pretty _useful_ as one of methods to open proxy/relay reliable testing and it's included in FreeBSD ports collection. Should i care if it wasn't updated for 2 years? The main concern is that security bugs may come up. And in that case the upstream should jump in quickly and help to fix it. If the upstream software became unmaintained then the situation may lead to the removal of the package. It's okay if the last update is a year ago. I just wanted to make sure you talked to the upstream at least once. Waiting for the answer. - The package is not lintian clean. Three issues there. Do you mean issues above or something other? I saw only one: $ lintian dsbltesters_0.9.5-1.dsc W: dsbltesters source: out-of-date-standards-version 3.6.1 I got these messages: W: dsbltesters source: out-of-date-standards-version 3.6.1 E: dsbltesters: file-in-etc-not-marked-as-conffile /etc/dsbl.conf W: dsbltesters: old-fsf-address-in-copyright-file Could you be so kind to check dsbltesters_0.9.5-2? Just did. Still not lintian clean. Did you use a current Sid (unstable) installation to build the package? These are the remaning messages: E: dsbltesters: file-in-etc-not-marked-as-conffile /etc/dsbl.conf W: dsbltesters: old-fsf-address-in-copyright-file Please make sure your package are lintian-clean. Hmm... The history follows. I made built package checks under my usual system (testing), and now i see that it should be produced in pbuilder environment. I just added linda- and lintian-hooks to pbuilder (DISTRIBUTION=testing). They reports: Setting up linda (0.3.17) ... Linda: Running as root, dropping to nobody. E: dsbltesters; dsbl.conf is in /etc, but not marked as a conffile. Setting up lintian (1.23.14) ... E: dsbltesters: file-in-etc-not-marked-as-conffile /etc/dsbl.conf W: dsbltesters: old-fsf-address-in-copyright-file To me, it's a kind of magic, because i use up-to-date etch system and certanly same linda/lintian versions as for pbuilder environment. How come the difference? Anyway, now, pbuilder environment was upgraded for sid and next release should be lintian-clean. Be so nice, look at dsbl-testers_0.9.5-3... -- Regards, Al Nikolov JID [EMAIL PROTECTED]IRC clown UIN 312108671 PGP 4B50 F1E3 080C 21A2 91F4 8BF0 CD60 3B5A 2ECF 984B -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: proxycheck
Hi, there I'm seekig for new sponsor of existing package. Package: proxycheck Description: checks existence of open proxy License: GPL URL: http://www.corpit.ru/mjt/proxycheck.html Upstream Author: Michael Tokarev proxycheck is a simple tool that will work on a reasonable *nix system and may be used to quickly check whenever a given host or set of hosts has open proxy server running -- Regards, Al Nikolov JID [EMAIL PROTECTED]IRC clown UIN 312108671 PGP 4B50 F1E3 080C 21A2 91F4 8BF0 CD60 3B5A 2ECF 984B -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: proxycheck -- link
Al Nikolov wrote: Excuse me, forgot link to http://mentors.debian.net/debian/pool/main/p/proxycheck/ -- Regards, Al Nikolov JID [EMAIL PROTECTED]IRC clown UIN 312108671 PGP 4B50 F1E3 080C 21A2 91F4 8BF0 CD60 3B5A 2ECF 984B -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: dsbltesters
Christoph Haas wrote: I'd be generally willing to sponsor it, but... Thanks anyway. - Please close the WNPP bug 273204 which you opened yourself one and a half year ago. Ok, i'll close it. I assumed though that ITP should be closed after that the package was become ready and was appeared in the pool. I'm i wrong? - Please use the current standards version. No problem, i'll fix that. - The copyright file should contain the years of copyright. Ok, i'll fix that. BTW i see many copyright files in Debian packages whitout (c)year lines. Is it actually a violation? - There has been long time no change. Did you contact the upstream to make sure the software is still maintained? This piece of software is developed and distributed by dsbl.org project which acts as great free network service. I have no doubt, the software is pretty _useful_ as one of methods to open proxy/relay reliable testing and it's included in FreeBSD ports collection. Should i care if it wasn't updated for 2 years? I maintain an another package (proxycheck) which do almost the same and it also stays without aggressive development. IMHO, such a nature of the object: most of open proxies/relays are usual MUAs, HTTP servers and other well-known services in well-known insecure states. There is not so many news from the battlefield. Anyway, i've asked upstream about the software status. - Installing the README file doesn't seem to add any value for the end-user. Ok, i'll remove it. I assumed that README.Debian is the right place to point on specific build options. Debian includes needed development libraries, but the easiest way to debianize this software was just to link it against the supplied versions. Should i emphasize that somewhere? - The upstream tarball I just fetched from the web site has another md5 checksum than the orig.tar.gz you provide. How come? At a first diff -r glance the two files have many differences. $ md5sum dsbltesters_0.9.5.orig.tar.gz dsbl-testers-0.9.5.tar.gz 55285009d90914048df2f62f4c9525d8 dsbltesters_0.9.5.orig.tar.gz 55285009d90914048df2f62f4c9525d8 dsbl-testers-0.9.5.tar.gz For me, they are identical. Perhaps, you've downloaded by mistake dsbl-0.9.5.tar.gz which is server software. - The package is not lintian clean. Three issues there. Do you mean issues above or something other? I saw only one: $ lintian dsbltesters_0.9.5-1.dsc W: dsbltesters source: out-of-date-standards-version 3.6.1 Could you be so kind to check dsbltesters_0.9.5-2? -- Regards, Al Nikolov JID [EMAIL PROTECTED]IRC clown UIN 312108671 PGP 4B50 F1E3 080C 21A2 91F4 8BF0 CD60 3B5A 2ECF 984B -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: dsbltesters
Package: dsbltesters Description: open proxy/relay testing utilities License: GPL URL: http://dsbl.org/programs Upstream Authors: Rik van Riel, Ian Gulliver, Ron Guilmette, Fred Smith This package contains testing software configured to work with the DSBL (http://dsbl.org/) or DSBL-compliant services. It enables you to send tests to servers based on spam that you receive. If those tests succeed, the results will reach the DSBL host in question, and the relay will be listed. It can be downloaded from: http://mentors.debian.net/debian/pool/main/d/dsbltesters/ -- Regards, Al Nikolov JID [EMAIL PROTECTED]IRC clown UIN 312108671 PGP 4B50 F1E3 080C 21A2 91F4 8BF0 CD60 3B5A 2ECF 984B -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: dsbltesters - open proxy/relay testing utilities
Hi, all Seeking for sponsorship for the package (ITP: 273204) Package: dsbltesters Version: 0.9.5-1 Section: net Priority: optional Description: open proxy/relay testing utilities This package contains testing software configured to work with the DSBL (http://dsbl.org/) or DSBL-compliant services. It enables you to send tests to servers based on spam that you receive. If those tests succeed, the results will reach the DSBL host in question, and the relay will be listed. -- Regards, Al Nikolov JID [EMAIL PROTECTED]IRC clown UIN 312108671 PGP 4B50 F1E3 080C 21A2 91F4 8BF0 CD60 3B5A 2ECF 984B -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bad input checking - a bug?
Hello, all Please consult me. A bad checking of unexpected command-line arguments causing segmentation fault - is that behaviour must be counted as a grave/normal/minor bug? -- Regards, Al Nikolov -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
backporting
Hi, all Point me to sources describing the Debian way of backporting pls -- Regards, Al Nikolov
RFS: proxycheck
Hi, all Looking for sponsor for a new package: http://mentors.debian.net/debian/dists/unstable/main/binary-i386/proxycheck/ Description: A simple tool to quickly recon a running open proxy server proxycheck is a simple tool that will work on a reasonable *nix system and may be used to quickly check whenever a given host or set of hosts has open proxy server running (No, I will not adapt it to run on winbloze machine, don't ever ask me about this). Open proxies of various kinds are (ab)used nowadays for various evil things like sending mass spam, hacking into your machine, making denial of service attacks (DoS) and the like. Every such machine should be either secured properly or turned off permanently, but that's not an option, since in most cases there is either no administrator of such machines exists at all, or he has no clue about what's on that machine, or it's irrelevant for him. I tried to contact with several owners of such open proxy servers, but almost without any success so far. So the only way to stop massive abuse made via such machines is to block them. But before it is possible, one need to know whenever any machine runs such service or not. Also, network administrators (of an ISP for example) are able to warn their clients whenever they are running an insecure proxy services - periodical scanning of client's network may also be a good idea. This command-line tool, proxycheck, may be used for such purpose. Currently, it understands 3 types of proxy servers: HTTP proxies that allows you to CONNECT to any host:port, SOCKS v4 and v5 proxies (http://www.socks.permeo.com/, originally http://www.socks.nec.com/), wingate telnet proxy servers of various kinds (incl. e.g. CCProxy variants and others), and FTP proxies that are able to create transparent connections. It makes connections to either a set of given ports or to default ports on a given list of IP addresses and tries to convince a service on the remote side to make another connection to a destination specified on proxycheck's command line. If that will success, proxycheck when runs some specified action - tries to talk with a destination system, and if the dialog was successful, it assumes the proxy server to be open. A destination you give to proxycheck will usually be your own machine, with a well-known service running on some port that replies to any connection attempt with a well-known fixed string. Typical example is your own mailserver on port 25: whenever someone connect to this port, an SMTP greeting message will be sent to remote. So if you tell proxycheck to attempt to make proxy connection to your own mail server, it will be sufficient to treat that proxy as open if proxycheck will see your smtp server's standard greeting message. proxycheck is able to test many different IP addresses and ports simultaneously, to speed up testing. It will try to open as many connections in parallel as allows by your system's resources, or up to specified limit. So it is possible to scan the whole networks using this tool. But be warned that doing so may be not what owners of those networks likes. -- Regards, Al Nikolov Informational and Analytics Centre of Saint-Petersburg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: proxycheck
Hi, all Looking for sponsor for a new package: http://mentors.debian.net/debian/dists/unstable/main/binary-i386/proxycheck/ Description: A simple tool to quickly recon a running open proxy server proxycheck is a simple tool that will work on a reasonable *nix system and may be used to quickly check whenever a given host or set of hosts has open proxy server running (No, I will not adapt it to run on winbloze machine, don't ever ask me about this). Open proxies of various kinds are (ab)used nowadays for various evil things like sending mass spam, hacking into your machine, making denial of service attacks (DoS) and the like. Every such machine should be either secured properly or turned off permanently, but that's not an option, since in most cases there is either no administrator of such machines exists at all, or he has no clue about what's on that machine, or it's irrelevant for him. I tried to contact with several owners of such open proxy servers, but almost without any success so far. So the only way to stop massive abuse made via such machines is to block them. But before it is possible, one need to know whenever any machine runs such service or not. Also, network administrators (of an ISP for example) are able to warn their clients whenever they are running an insecure proxy services - periodical scanning of client's network may also be a good idea. This command-line tool, proxycheck, may be used for such purpose. Currently, it understands 3 types of proxy servers: HTTP proxies that allows you to CONNECT to any host:port, SOCKS v4 and v5 proxies (http://www.socks.permeo.com/, originally http://www.socks.nec.com/), wingate telnet proxy servers of various kinds (incl. e.g. CCProxy variants and others), and FTP proxies that are able to create transparent connections. It makes connections to either a set of given ports or to default ports on a given list of IP addresses and tries to convince a service on the remote side to make another connection to a destination specified on proxycheck's command line. If that will success, proxycheck when runs some specified action - tries to talk with a destination system, and if the dialog was successful, it assumes the proxy server to be open. A destination you give to proxycheck will usually be your own machine, with a well-known service running on some port that replies to any connection attempt with a well-known fixed string. Typical example is your own mailserver on port 25: whenever someone connect to this port, an SMTP greeting message will be sent to remote. So if you tell proxycheck to attempt to make proxy connection to your own mail server, it will be sufficient to treat that proxy as open if proxycheck will see your smtp server's standard greeting message. proxycheck is able to test many different IP addresses and ports simultaneously, to speed up testing. It will try to open as many connections in parallel as allows by your system's resources, or up to specified limit. So it is possible to scan the whole networks using this tool. But be warned that doing so may be not what owners of those networks likes. -- Regards, Al Nikolov Informational and Analytics Centre of Saint-Petersburg
Seeking sponsor for proxycheck
Hi, all Just packaged the proxycheck - a simple tool to quickly recon a running open proxy server - and need sponsorship to become Dedian contributor. Please promote. The package is available at: http://bilbo.gorod-spb.ru/~al/debian/ -- Regards, Al Nikolov Informational and Analytics Centre of Saint-Petersburg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Seeking sponsor for proxycheck
Hi, all Just packaged the proxycheck - a simple tool to quickly recon a running open proxy server - and need sponsorship to become Dedian contributor. Please promote. The package is available at: http://bilbo.gorod-spb.ru/~al/debian/ -- Regards, Al Nikolov Informational and Analytics Centre of Saint-Petersburg
