Re: dpkg-sig support wanted?
On Sat, 26 Nov 2005 14:14:38 +0100, Henning Makholm <[EMAIL PROTECTED]> wrote: >Scripsit Florian Weimer <[EMAIL PROTECTED]> >> I wouldn't use real base64, though, because it would mean that you can >> use its hashed output as a file name. > >Good point. One might replace "/" with "_" and omit the final "=". >Having a "+" in the hash should be safe in most contexts. Isn't base62, which for example exim uses to create its message-ids, a standard? I have never seen it outside exim. Greetins Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: dpkg-sig support wanted?
On Sun, Nov 27, 2005 at 02:18:00PM +1000, Anthony Towns wrote: > My understanding was that there aren't other hash functions that've had > remotely similar levels of cryptographic analysis to md5 and sha. IIRC, > the elliptic curve cryptography stuff was supposed to be similarly neat, > until people started analysing it seriously, at which point it broke. To the best of my knowledge, elliptic curve cryptography isn't any more broken than RSA or ElGamal is. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: possible freetype transition; improved library handling needed for all C/C++ packages
On Tue, Nov 22, 2005 at 02:37:19PM -0800, Steve Langasek wrote: > Due to upstream ABI changes, it looks very likely that libfreetype is > going to have to undergo a library transition in the near future[0]. > The details are still being settled, and it's possible (though unlikely) > that the library will be fixed so that no transition is needed, but in > the meantime I'd like to leave you all with a public service > announcement. [...] > This email, therefore, is a call-to-arms for maintainers to improve > the library handling in their packages. The impetus for this request is > the prospective freetype transition, but if you maintain *any* packages > in C and C++, this mail is still addressed to you. So, I found out that my trustedqsl package is fairly guilty in this regard. Not in regard to freetype, but it links directly to openssl and libexpat, even though it doesn't use them. Upstream's autoconf setup actually does this deliberately. I've trimmed the configure scripts to avoid this, leaving me with the link commands for the two binaries being: g++ -Wall `"/usr/bin/wx-config" --cxxflags` -I/usr/include -I/usr/include -I/usr/include -g -O2 -o tqsl tqsl.o extwizard.o tqslwiz.o dxcc.o stationdial.o qsodatadialog.o tqslvalidator.o tqsl_prefs.o wxutil.o -pthread -lwx_gtk-2.4 -ltqsllib g++ -Wall `"/usr/bin/wx-config" --cxxflags` -I/usr/include -I/usr/include -I/usr/include -g -O2 -o tqslcert tqslcert.o crqwiz.o dxcc.o certtree.o tqslcert_prefs.o getpassword.o extwizard.o loadcertwiz.o wxutil.o -pthread -lwx_gtk-2.4 -ltqsllib (wx-config --libs says "-pthread -lwx_gtk-2.4"). However, my built package depends on zlib1g, which it doesn't use directly and doesn't -l during link. I'd welcome any suggestions on how this might be... dpkg-shlibdeps bug? thanks Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: possible freetype transition; improved library handling needed for all C/C++ packages
On Sun, Nov 27, 2005 at 11:48:37PM +1100, Hamish Moffatt wrote: > > I've trimmed the configure scripts to avoid this, leaving me with the > link commands for the two binaries being: > > g++ -Wall `"/usr/bin/wx-config" --cxxflags` -I/usr/include -I/usr/include > -I/usr/include -g -O2 -o tqsl tqsl.o extwizard.o tqslwiz.o dxcc.o > stationdial.o qsodatadialog.o tqslvalidator.o tqsl_prefs.o wxutil.o -pthread > -lwx_gtk-2.4 -ltqsllib > > However, my built package depends on zlib1g, which it doesn't use > directly and doesn't -l during link. ./tqsl.cpp:#include And on line 691 you have a gzFile, 1157 calls gzopen, ... Your configure script also checks for it, and adds it. linking tqslcert to -lz doesn't seem to be needed though. > I'd welcome any suggestions on how this might be... dpkg-shlibdeps bug? This is a linker feature which I dislike. It adds missing libraries if one of the libraries you link to happens to be linked to the one you need. For more info see: http://sourceware.org/ml/binutils/2005-09/msg00200.html Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
In linux.debian.devel, you wrote: > Worse, the existance of a practical md5(A+B+C)=3Dmd5(A+D+C) attack means > that it's not out of the question that there're md5(A+B)=3Dmd5(C+D) > attacks in the hands of particularly well resourced groups (which is > worse, since the version uploaded to the archive could then be entirely > innocent looking). Personally, I don't have any interest in making the > NSA's job any easier, or that of other signals intelligence groups. While this is arguably true (the NSA claims to have developed asymmetric cryptography ten years ahead of Diffie/Hellman), it seems that nowadays the end of the cold war and improved corporate interest have shifted things, so I'm personally not _too_ worried about that. >> >> Moving away from MD5 is certainly not a bad idea, but it's not clear >> >> whether the alternatives are any better. Sure, everyone recommends >> >> SHA-256 at this stage, but nobody can give a rationale. >> > MD5 is broken; SHA-1 is where MD5 was a couple of years ago, SHA256 (or >> > higher) are significantly harder to break in practice, >> So? If SHA256 is so much better, why is that nobody can prove it, or >> at least can provide some evidence which supports that claim? "The >> numbers are bigger" is the main argument at this point, which is >> awfully similar to the usual snake-oil arguments (although there is a >> slight difference, of course). > > SHA256 is better than SHA1 in the same way 2048 bit RSA keys are better > than 512 bit RSA keys. MD5 is broken, and isn't extensible. SHA1 is > fragile, but not broken, and is extensible. Do you have other > suggestions? I'd suggest the combination of several hash systems, e.g. RIPEMD-160, a SHA-based algorithm and possibly Tiger. >> > and there's nothing better yet. >> In terms of security, there are some better hash functions. =20 > > My understanding was that there aren't other hash functions that've had > remotely similar levels of cryptographic analysis to md5 and sha. IIRC, > the elliptic curve cryptography stuff was supposed to be similarly neat, > until people started analysing it seriously, at which point it broke. I'm not aware of any attacks beyond birthday attacks, which are still infeasible for the recommended key sizes of >= 160 bits. ECC has several patent problems, though. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#340934: lintian check for unneeded/transitive shlibs dependencies
Scripsit Peter Samuelson > [Henning Makholm] > > I have written a Lintian check which attempts to flag instances of > > this problem. It looks for ELF objects that flag shared libraries in > > the default search path as NEEDED without actually importing symbols > > that the library exports. > This produces a lot of noise in a case where a package has multiple > binaries or libraries (sometimes in multiple packages), and a Makefile > that links everything to a common set of libs which not everything > needs. Your check flags this correctly, but it can be a real pain to > fix, and doesn't usually cause practical problems - particularly the > problem Steve writes about. Remember, the granularity of testing > migrations and library transitions is not the file or even the binary > package, but the source package. This appears to be a fair point. I think I'll revise my proposal so it works per .deb rather than per object file. I'd like to see some broader debate, however. I am not conviced that the entire _source_ package is the right level to check this at. Steve mentioned two problems - one is painfullness of library transitions, the other is segfaults in case of partial upgrades. While the first problem indeed works on the source package level, the second is often a matter between binary packages with the same source. For a concrete example, consider #260938. The autotrace source package builds binary packages libautotrace3 and autotrace; the latter contains a client for the library in the former. A user upgraded the client package without upgrading the library. This _ought_ to have worked because the ABI of the library itself was indeed unchanged. But the upgraded client spuriously pulled in different versions of some library that was, in fact, used only by libautotrace, and a segfault resulted. Had a lintian check for spurious linking existed at the time, I would have noticed that the client binary requested too many shared libs and have an opportunity to fix it because it hit a user with a sefault. -- Henning Makholm "This imposes the restriction on any procedure statement that the kind and type of each actual parameter be compatible with the kind and type of the corresponding formal parameter." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#341012: ITP: kalgebra -- calculator based on MathML language
Package: wnpp Severity: wishlist Owner: Steffen Joeris <[EMAIL PROTECTED]> * Package name: kalgebra Version : 0.4 Upstream Author : Aleix Pol <[EMAIL PROTECTED]> * URL : http://kalgebra.berlios.de/ * License : GPL Description : calculator based on MathML language KAlgebra is a mathematical calculator based content markup MathML language. Nowadays it is capable to make simple MathML operations (arithmetic and logical) and representate 2D and 3D graphs. It is actually not necessary to know MathML to use KAlgebra. . The Mathematical Markup Language, is an XML based language used for displaying mathematical notation and content, especially on the web. It is a World Wide Web Consortium (W3C) recommended standard, and has been receiving increasing support by mathematical software vendors. . Web site: http://kalgebra.berlios.de/ -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-2-686 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: possible freetype transition; improved library handling needed for all C/C++ packages
On Sun, Nov 27, 2005 at 02:31:05PM +0100, Kurt Roeckx wrote: > On Sun, Nov 27, 2005 at 11:48:37PM +1100, Hamish Moffatt wrote: > > g++ -Wall `"/usr/bin/wx-config" --cxxflags` -I/usr/include -I/usr/include > > -I/usr/include -g -O2 -o tqsl tqsl.o extwizard.o tqslwiz.o dxcc.o > > stationdial.o qsodatadialog.o tqslvalidator.o tqsl_prefs.o wxutil.o > > -pthread -lwx_gtk-2.4 -ltqsllib > > > > However, my built package depends on zlib1g, which it doesn't use > > directly and doesn't -l during link. > > ./tqsl.cpp:#include > And on line 691 you have a gzFile, 1157 calls gzopen, ... So it does. (And so much for my grep skills.) > Your configure script also checks for it, and adds it. linking Not as of 1.11-3, where I removed the checks for libz, libexpat and libssl. The latter two definitely aren't needed, and do disappear from the binary package's Depends line as a result. > tqslcert to -lz doesn't seem to be needed though. > > > I'd welcome any suggestions on how this might be... dpkg-shlibdeps bug? > > This is a linker feature which I dislike. It adds missing > libraries if one of the libraries you link to happens to be > linked to the one you need. For more info see: > http://sourceware.org/ml/binutils/2005-09/msg00200.html Interesting. Thanks. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: possible freetype transition; improved library handling needed for all C/C++ packages
On Sun, 27 Nov 2005, Hamish Moffatt wrote: > On Tue, Nov 22, 2005 at 02:37:19PM -0800, Steve Langasek wrote: > > Due to upstream ABI changes, it looks very likely that libfreetype is > > going to have to undergo a library transition in the near future[0]. > > The details are still being settled, and it's possible (though unlikely) > > that the library will be fixed so that no transition is needed, but in > > the meantime I'd like to leave you all with a public service > > announcement. > > [...] > > > This email, therefore, is a call-to-arms for maintainers to improve > > the library handling in their packages. The impetus for this request is > > the prospective freetype transition, but if you maintain *any* packages > > in C and C++, this mail is still addressed to you. > > So, I found out that my trustedqsl package is fairly guilty in this > regard. Not in regard to freetype, but it links directly to openssl and > libexpat, even though it doesn't use them. Upstream's autoconf setup > actually does this deliberately. > > I've trimmed the configure scripts to avoid this, leaving me with the > link commands for the two binaries being: > > g++ -Wall `"/usr/bin/wx-config" --cxxflags` -I/usr/include -I/usr/include > -I/usr/include -g -O2 -o tqsl tqsl.o extwizard.o tqslwiz.o dxcc.o > stationdial.o qsodatadialog.o tqslvalidator.o tqsl_prefs.o wxutil.o -pthread > -lwx_gtk-2.4 -ltqsllib > > g++ -Wall `"/usr/bin/wx-config" --cxxflags` -I/usr/include -I/usr/include > -I/usr/include -g -O2 -o tqslcert tqslcert.o crqwiz.o dxcc.o certtree.o > tqslcert_prefs.o getpassword.o extwizard.o loadcertwiz.o wxutil.o -pthread > -lwx_gtk-2.4 -ltqsllib And what does wx-config produce? Please expand everything when asking questions. > (wx-config --libs says "-pthread -lwx_gtk-2.4"). But you use --cxxflags. > However, my built package depends on zlib1g, which it doesn't use > directly and doesn't -l during link. objdump -p $binary|grep NEEDED. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#340934: lintian check for unneeded/transitive shlibs dependencies
On Sun, Nov 27, 2005 at 06:05:52PM +0100, Henning Makholm wrote: > > > I have written a Lintian check which attempts to flag instances of > > > this problem. It looks for ELF objects that flag shared libraries in > > > the default search path as NEEDED without actually importing symbols > > > that the library exports. > > This produces a lot of noise in a case where a package has multiple > > binaries or libraries (sometimes in multiple packages), and a Makefile > > that links everything to a common set of libs which not everything > > needs. Your check flags this correctly, but it can be a real pain to > > fix, and doesn't usually cause practical problems - particularly the > > problem Steve writes about. Remember, the granularity of testing > > migrations and library transitions is not the file or even the binary > > package, but the source package. > This appears to be a fair point. I think I'll revise my proposal so it > works per .deb rather than per object file. > I'd like to see some broader debate, however. I am not conviced that > the entire _source_ package is the right level to check this at. Steve > mentioned two problems - one is painfullness of library transitions, > the other is segfaults in case of partial upgrades. While the first > problem indeed works on the source package level, the second is often > a matter between binary packages with the same source. I agree that we need better granularity than per-source. I actually think that having it per object file is ideal in the long run, though in the short term doing it per binary package means less confusing noise. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Chao ban ve may bay
Ban cho toi gia bay noi dia tiuyen Hanoi - Daklak vao ngay 29,30/11/2005. Gia re nhat.
Re: dpkg-sig support wanted?
On Sun, Nov 27, 2005 at 12:42:42PM +0100, Steinar H. Gunderson wrote: > On Sun, Nov 27, 2005 at 02:18:00PM +1000, Anthony Towns wrote: > > My understanding was that there aren't other hash functions that've had > > remotely similar levels of cryptographic analysis to md5 and sha. IIRC, > > the elliptic curve cryptography stuff was supposed to be similarly neat, > > until people started analysing it seriously, at which point it broke. > To the best of my knowledge, elliptic curve cryptography isn't any more > broken than RSA or ElGamal is. Oh god, how embarassing. I'm confusing elliptic curves and knapsacks, my bad. Knapsack cryptograph's "provably" secure (in that a general solution is NP), and practically insecure (in that it's hard to find instances that are reliably hard enough, at least without obscene key sizes). But hey, SHA-something, Tiger, or whatever; it's well past time to choose one, get a /usr/bin/<...> binary we can use, and replace md5 with it. Cheers, aj signature.asc Description: Digital signature
Re: master mail problems -- help needed
* Stephen Gran: > No noticable time difference between the two, either. So, I don't > think this is the real problem. You could be right. The problem is still present, unfortunately. One more data point: A couple of seconds before the last bounce was generated, murphy (which is on the same network as master) successfully delivered mail to mail.enyo.de. It doesn't seem to be related to connectivity issues on my part. postmaster@ has been contacted, I'm waiting for log excerpts from DSA. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
On Sun, Nov 27, 2005 at 12:42:42PM +0100, Steinar H. Gunderson wrote: > On Sun, Nov 27, 2005 at 02:18:00PM +1000, Anthony Towns wrote: >> My understanding was that there aren't other hash functions that've >> had remotely similar levels of cryptographic analysis to md5 and >> sha. IIRC, the elliptic curve cryptography stuff was supposed to be >> similarly neat, until people started analysing it seriously, at >> which point it broke. > To the best of my knowledge, elliptic curve cryptography isn't any > more broken than RSA or ElGamal is. It isn't really broken, but the recommended key sizes have grown significantly. I mean, the factor to divide RSA/DH/ElGamal key sizes by to get equivalent security in ECC has shrunk. At least, I've heard so, I don't remember what keys sizes were advertised in the beginnings of ECC. -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
On Mon, Nov 28, 2005 at 03:32:21PM +1000, Anthony Towns wrote: > Knapsack cryptograph's "provably" secure (in that a general solution > is NP), You mean NP-_complete_. (Sorting is also NP, but not NP-complete. NP is "can be done in polynomial time by a non-deterministic Turing machine, so anything polynomial by a normal machine is also NP. "Foo is NP-complete" is "any NP problem can be polynomially reduced to foo", or in other words, if there is a normal machine that does foo in polynomial time, all NP problems can be done in polynomial time.) -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: texlive-basic_2005-1_i386.changes REJECTED
Hi Jörg, hi ftpmasters! (I take in debian-devel and debian-tetex-maint) I want to add some comments and questions: First, genesis of TeX live for Debian. This probably/hopefully answers "the big ?" of you: Following the ITP #312897 there was quite a bit of discussion on debian-devel on the topic why to include another TeX distribution, especially one that big. (ITP: http://lists.debian.org/debian-devel/2005/06/msg00970.html) There it is also stated that although TeX live is also a Live TeX distribution, it is also one of the most complete TeX system currently available. Furthermore it has the advantage that it is already split into smaller packages. Frank Küster, the maintainer of teTeX packages, summed up the advantages of having TeX live in Debian, explaining why it should be included (see http://lists.debian.org/debian-devel/2005/06/msg01103.html). The package splitting strategy was developed in cooperation with the TeX live upstream maintainers (via the [EMAIL PROTECTED] ml), and the teTeX maintainers (starting in late 2004 beginning of 2005): http://lists.debian.org/debian-tetex-maint/2005/01/msg00228.html It boils down to the following: In TeX live upstream there are packages (called tpm - tex package management) for each single package from CTAN. These tpms are grouped together in areas of interest called `collections'. In the discussion on the package split policy we came to the conclusion that it is not feasable to make one debian package from one tpm, that would be around 1000+ different packages. So we decided to go for transforming collections into debian packages. Now for your comments: On Son, 27 Nov 2005, Joerg Jaspert wrote: > Looking at the texlive packages in NEW I have some comments for you, > leaving alone my big ? why one wants to include basically a ctan mirror > in debian / dupe many things with tetex, instead of simply putting more > man-power/work into tetex if its not modular enough. See Franks comment above. Or: How many users of TeX packages have to go through the difficult process of installing packages by hand from the CTAN archive only to see that it is not working. It is not a completely trivial task, even for experienced sysadmins. To have a more or less complete TeX system in Debian is not a useless addition, it helps those working with TeX and more than the set included in teTeX. > Looking at what I know from texlive its intended as a live thingie for > users to play/start with tex? Is there such a huge userbase for this to No. Definitely not. Please see the web pages of texlive: http://www.tug.org/texlive. It is used on a wide range of platforms and operating systems, and normally is installed. It is *not* primary a live system (although the name suggests this). > Im also not really happy with the current packaging, starting with the too > heavy split of (source) packages. Ok, this can be dealt with. I thought it would be better to have a strict relation between source and bin packages, but where it was not possible. > For example there are 19 documentation source packages, all building one > binary. Better merge them into one texlive-source and build the > different binary packages out of that one. You are left with 47 sources. > > Similar things can be said for the language packs, merge the *27* to one > and built the binaries out of that. Down to 21 sources. :) Ok, this is no problem. The .orig.tar.gz will be bigger, but I can merge the source packages without any problem. > Also I *suggest* to add a - after lang, so it reads lang-FOO, which is > *IMO* easier. (Well, for all packages which dont have the additional -). The reason behind this decision was to have the package name reflecting the collection name, so that people using TeX live and using Debian see (+-) the same names. > as you do now with 65. Yes, that makes the orig-tarballs bigger, but I > dont think thats so much of a problem here. Ok, will do this. > allrunes dfsg > > Please: Tell me its not true that the DFSG is used as a license there. As stated in the License file, this list was generated from the TeX Catalogue, which *can be wrong*! If you check the actual allrunes files, you see that it is LPPL. So for the further proceeding: I will generate a new set of .orig.tar.gz etc with a new source packages splitting scheme, trying to reduce the source packages as much as possible. Here a question: Theoretically I can make only *ONE* source package. That would make *many* *many* things *much* more easier. But, this would be rather big a .orig.tar.gz. In my understanding of the packaging process this is not what is wished, but please correct me! Especially I don't see the advantage of having such a big source package, fixes always would force a big rebuild of everything. For the package names I would prefer staying at the current names, as the relate to the TeX live collection names. But if ftpmasters would not accept, I will change. What further steps are necessary to get t
Re: dpkg-sig support wanted?
On Sat, Nov 26, 2005 at 10:59:57AM +0100, Florian Weimer wrote: > * Anthony Towns: >> On Fri, Nov 25, 2005 at 07:59:40PM +0100, Florian Weimer wrote: >>> * Anthony Towns: >>> Moving away from MD5 is certainly not a bad idea, but it's not >>> clear whether the alternatives are any better. Sure, everyone >>> recommends SHA-256 at this stage, but nobody can give a rationale. >> MD5 is broken; SHA-1 is where MD5 was a couple of years ago, SHA256 >> (or higher) are significantly harder to break in practice, > So? If SHA256 is so much better, why is that nobody can prove it, > or at least can provide some evidence which supports that claim? The idea behind using SHA256 (or SHA512) is that we have more _margin_. If we are targeting MD5's design security (2^64 against collisions), even if SHA512 is "broken" significantly - say an attack four times better than birthday - we still have our expected strength. It is also the best we can get to *right* *now*, unless we escape to humongous hash sizes (arithmetic-based designs). >> and there's nothing better yet. > In terms of security, there are some better hash functions. But > those are academic designs, most of them based on big integer > arithmetic instead of bit fiddling. Currently, nobody seems to be > willing to pay the price that comes with them. What this means is that your hashes will be as big as your asymmetric keys, and hashing as slow as asymmetric cryptography. That's significant. They also seem to have deeply different security properties as far as the user is concerned: the one I know, at least (http://diswww.mit.edu/bloom-picayune/crypto/13190) relies (as asymmetric crypto) on n a hard to factor product of two primes p and q. The "security proof under assumption that factoring is hard" is that if you generate a collision, you have factored n (roughly). Now, what I don't get is who generates n and thus knows p and q and thus _can_ generate collisions? Does everyone use his own n (and thus everyone can generate collisions for the hash _he_ uses, but not for the hash others use), do we use a trusted third party (that's a _significantly_ different security model!) that publishes n? (When I write n above, I obviously mean the pair (n,g), g element of maximal order in Z/nZ.) -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: texlive-basic_2005-1_i386.changes REJECTED
On Mon, 28 Nov 2005, Norbert Preining wrote: > (I take in debian-devel and debian-tetex-maint) For completeness I attach the complete email of Jörg. Best wishes Norbert --- Dr. Norbert Preining Università di Siena gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- WEST WITTERING (participial vb.) The uncontrollable twitching which breaks out when you're trying to get away from the most boring person at a party. --- Douglas Adams, The Meaning of Liff --- Begin Message --- Hi Maintainer(s), Looking at the texlive packages in NEW I have some comments for you, leaving alone my big ? why one wants to include basically a ctan mirror in debian / dupe many things with tetex, instead of simply putting more man-power/work into tetex if its not modular enough. Looking at what I know from texlive its intended as a live thingie for users to play/start with tex? Is there such a huge userbase for this to include it (hey, its >600MB) into Debian? Im also not really happy with the current packaging, starting with the too heavy split of (source) packages. You have 65 of them right now. For example there are 19 documentation source packages, all building one binary. Better merge them into one texlive-source and build the different binary packages out of that one. You are left with 47 sources. Similar things can be said for the language packs, merge the *27* to one and built the binaries out of that. Down to 21 sources. :) Also I *suggest* to add a - after lang, so it reads lang-FOO, which is *IMO* easier. (Well, for all packages which dont have the additional -). To not repeat too much: The same goes for all different source packages that are splitted into recommended/extra/whatever. I think you can end up with less than 20 source packages, building up the same functionality as you do now with 65. Yes, that makes the orig-tarballs bigger, but I dont think thats so much of a problem here. Oh, if I go and read the included Licenses.txt i see they have the following listed: # The licenses codes as described on # http://www.ctan.org/tex-archive/help/Catalogue/licenses.html # are # DFSG free licenses: # dfsg Debian Free Software Guidelines # artisticPerl Artistic License [... and so on] and a bit down: allrunes dfsg (and more package) Please: Tell me its not true that the DFSG is used as a license there. Note: Feel free to move the discussion to the -devel list if you want. -- bye Joerg === If you don't understand why your files were rejected, or if the override file requires editing, reply to this email. --- End Message ---
