From isbaran at gmail.com Wed Apr 2 01:26:08 2008 From: isbaran at gmail.com (Isbaran Akcayir) Date: Wed, 02 Apr 2008 01:26:08 +0300 Subject: [Gsoc] 802.1x support for network-manager Message-ID: <47F2B680.4020003@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello everyone, Here is an idea we discussed about while building a radius server at university for eduroam [1] For those wondering what 802.1x is about: see [2] Because radius servers and places using 802.1x are growing in number ( Well, not growing still, but related law no. 5651 [4] from TBMM [3] which simply obligates saving all the communication logs, users, connection points inside local or wide area networks, makes me think its growing in number :) ) there should be some configuration tool for this communication type. Currently network manager wireless access settings are short (only user name and password is available) that wont allow users to choose eap method, certificate files, keys or anonymous identities needed. First goal of the project should be extending network-manager this way, allowing configuring 802.1x easily, as you would expect from a desktop distribution. Another idea would be creating a GUI for configuring server related tools ( for freeradius for example ) but this is not related to Pardus and is a lot more work. I wanted to hear your ideas before adding this to project ideas page of gsoc. Regards, i?baran [1] eduroam (EDUcation ROAMing) is the roaming infrastructure used by the international research and education community that provides the eduroam user experience: open your laptop and be online. Being part of eduroam allows users to access a wireless network at a visited institution (also connected to eduroam) simply using the same credentials (for instance, username and password) the users would use if they were at their home institution. [2] IEEE 802.1x security technology is a port based network access control technology. Simply, there are three nodes in structure. Supplicant(client), Authenticator(AP) and Authentication Server(AS). Theres a secure connection between AS and AP. ( Think of a server(usually a radius server) and a access point connected with one cable like in wireless networks ) AP sends an "EAP-Request/Identity" packet to the supplicant as soon as it detects that the link is active (ex: the supplicant system has associated with the access point). Client uses the only open port of AP to authenticate, data is transferred enrypted. Than "EAP-Response/Identity" pacakge of supplicant is passed to AS for authentication and on success AP opens other ports for that client allowing the access to LAN. Because all the data is transferred encrypted, and its not possible to monitor ( like in wireless networks, or like listening broadcast messages from eth. ) anything. This is the really secure way to communicate these days :) http://en.wikipedia.org/wiki/802.1x http://www.ieee802.org/1/pages/802.1x.html [3] http://www.tbmm.gov.tr/english/english.htm [4] http://www.tbmm.gov.tr/kanunlar/k5651.html Turkish -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (GNU/Linux) iD8DBQFH8raAA0iJ3Em80nwRAhbzAJ9dLoxhcU8DI3xoSYQy/OYcOA9zvwCfZo/o 6bO+XmyCEIk2rJ7Zjf/VmHI= =Hpul -----END PGP SIGNATURE----- From ozan at pardus.org.tr Fri Apr 4 10:01:45 2008 From: ozan at pardus.org.tr (=?UTF-8?B?T3phbiDDh2HEn2xheWFu?=) Date: Fri, 04 Apr 2008 10:01:45 +0300 Subject: [Gsoc] Building a new and compatible CUPS API interface for KDE distro's? In-Reply-To: <47EDFB5D.8050108@xs4all.nl> References: <47EDFB5D.8050108@xs4all.nl> Message-ID: <47F5D259.8000402@pardus.org.tr> Michiel Zandbelt wrote: > Yesterday for the third or fourth time I ran into this annoying > KDE<--->CUPS bug in that my printer that used to work fine, no longer > reacts on print jobs (these stayed queued) and 127.0.0.1:631 gives a 404 > not found error instead of CUPS config page. > The previous times I could only solve this problem by re-installing my > whole Pardus OS. > However now I was up and running again and had already finetuned my > Pardus, I do not want to re-install it agaian. > > Is there a quick solution for this remaining bug? > I'm not having this problem but it seems that the CUPS daemon is not working properly. Can you report this on http://bugs.pardus.org.tr? > I noticed after a Google search that it is a more general problem > already since 2006! > > KDEPrint is not mutually compatible with newer versions of CUPS and > KDEPrint as a project is not maintained very intense anymore. > > This then is a major issue for all KDE Linux distro's I guess. > > Now "we" are working on Pardus 2008, wouldn't it be usefull to implement > a TASMA configuration part based on the CUPS API itself instead of based > at the KDEPrint thing? The latter lacks compatability. > > Maybe a nice idea for the Google Summer of Code contest? > Of course that would be a nice idea for GSoC. The printing module in TASMA has a lot of functionality but needs reorganization. Don't hesitate to apply on GSoC, present your ideas clearly. Cheers -- Ozan ?A?LAYAN http://cekirdek.pardus.org.tr/~ozan From faik at pardus.org.tr Fri Apr 4 15:00:20 2008 From: faik at pardus.org.tr (Faik Uygur) Date: Fri, 4 Apr 2008 15:00:20 +0300 Subject: [Gsoc] GSOC 2008 In-Reply-To: References: Message-ID: <200804041500.20523.faik@pardus.org.tr> On Friday 28 March 2008 23:28:48 Mali Ozbay wrote: > Merhabalar, Merhabalar, > Benim ismim Mehmet Ozbay, University of Houston/Texas da application > developer olarak calisiyorum, hemde masterima yonelik dersler aliyorum. Bu > maili yazma sebebim GSOC 2008 ile ilgili pardus fikirlerinden hangilerinin > acik oldugu konusunda bilgi almak isteyisim. ( > http://en.pardus-wiki.org/SummerOfCode2008Ideas) Ideas sayfam?zdaki t?m fikirler a??kt?r. > 3 yildan beri acik kaynakli kod alaninda Zope ve Plone basta olmak uzere > proje tecrubem var, Su an itibariyle GSOC da Zope, Jython ve Turbo Gear > alanlarindaki girisimlerim devam ediyor, organizasyonlarin spesifik > politikalari yuzunden henuz sonuca yonelik bir izlenimim yok. Zope nesne > veri tabaninin Ms Sql baglanti adaptasyonu konusunda ki projem guclu bir > aday gibi gorunuyor. Bunun la beraber, pardus la ilgili bi seyler yapabilme > heyecanim cok guclu. Bir kac gundur bu mail listesinin yaninda > irc.freenodeda #pardus kanalinda da potensiyel hocalara ulasmaya > calistim. Kanalda her an bulunamayabiliyoruz bu y?zden bir gsoc mail listesi a?maya karar verdik. ?zg?r yaz?l?m tecr?benizin olmas? harika. Ba?vurular aras?nda yaz?l?m tecr?besi olmayan ya da ?ok az olan ??renciler de olabiliyor. Tabi ki bunlar?n hepsi de?erlendirme a?amas?nda ?nem kazan?yor. > Eger basvuruya hala acik fikirlerin listsine ulasabilirsem bu konularda > calisma sansimi gorebilir ve guclendirebilirim. Summer Of Code Ideas sayfam?zdaki t?m fikirler a??kt?r. E?er sizin kendinizin de bir fikri var ise, ideas sayfam?za ekleyebilir ve de Google ?zerinden yine proposal?n?z ile ba?vurunuzu yapabilirsiniz. > Zamaninizi ayirip okudugunuz icin tesekur ederim. Ba?vurular?n 7 Nisan'a kadar uzat?ld???n? da hat?rlatmak isterim. Tak?ld???n?z her hangi bir konu da sorular?n?z? bekleriz. > Selam ve Saygilarimla > Mehmet Selamlar, - Faik From necmettin.begiter at gmail.com Fri Apr 18 01:04:14 2008 From: necmettin.begiter at gmail.com (Necmettin Begiter) Date: Fri, 18 Apr 2008 01:04:14 +0300 Subject: [Gsoc] A proposal about package signing/verification Message-ID: <3787dfa80804171504j312f24b6x5278da815c044d6f@mail.gmail.com> First, if I'm mistaken or if failed to understand the aim behind this idea, forgive my limited knowledge and understanding of the issue. Here is what I understand of "a package verification system": We want to track if we are "acknowledged" of a package's existence/acceptance. We don't want pisi to install packages that we don't know of. And here is my proposal as a solution to this issue: A database table that holds package names, versions and md5 sums. When the user wants to install a package, pisi would ask the database for the md5 sum of that package, if the sums don't match, that means we don't know of this package, it should not be installed or the user should be informed that the package is not in the database and to install the package may harm the system; which I believe would make it unnecessary to "sign" any package (I might be wrong about this last part). Comments? Necmettin From serdar at cclub.metu.edu.tr Fri Apr 18 03:38:14 2008 From: serdar at cclub.metu.edu.tr (Serdar Dalgic) Date: Fri, 18 Apr 2008 03:38:14 +0300 Subject: [Gsoc] A proposal about package signing/verification In-Reply-To: <3787dfa80804171504j312f24b6x5278da815c044d6f@mail.gmail.com> References: <3787dfa80804171504j312f24b6x5278da815c044d6f@mail.gmail.com> Message-ID: <4807ED76.8080907@cclub.metu.edu.tr> Hi to all Necmettin Begiter wrote On 18-04-2008 01:04: > First, if I'm mistaken or if failed to understand the aim behind this > idea, forgive my limited knowledge and understanding of the issue. > > Here is what I understand of "a package verification system": We want > to track if we are "acknowledged" of a package's existence/acceptance. > We don't want pisi to install packages that we don't know of. > > I think we can extend this issue to a "chain of trust" mechanism from the maintainer of the package to the end-user. It would include maintainer's signature for uploading the file to the database, maybe an archive key for the distribution, and several more security/trust mechanisms. At the end, pisi should be aware of installing packages that are claimed to be "not changed" on road =) > And here is my proposal as a solution to this issue: A database table > that holds package names, versions and md5 sums. When the user wants > to install a package, pisi would ask the database for the md5 sum of > that package, if the sums don't match, that means we don't know of > this package, it should not be installed or the user should be > informed that the package is not in the database and to install the > package may harm the system; which I believe would make it unnecessary > to "sign" any package (I might be wrong about this last part). > > Comments? > > I agree with your proposal. It seems exact, however the md5sums may be altered while the files are being transmitted. Several changes would be beneficial for this signing mechanism proposal. Your "database-table" structure may be extended to a "release" file. This release file would possess the md5sums of the packages (and maybe SHA1sums of the packages as files.xml of every package has SHA1sum of the package) . And also this file would be signed with Distribution Key. (signing with OpenGPG would be sufficient). This release file should be updated as any of the packages in the archive change.. The user should enter this key to his/her own keyring for success. So when somebody tries to install a package, pisi will check whether the release files match and signed with distribution key; otherwise tell the user that the packages s/he is trying to install may harm his/her system, but also pisi gives the chance to continue.. User may have the chance to keep on installing the "unsigned" package, but pisi freaks out on every step (or one in two steps =) ) that's a little bit "fork" of debian's apt-secure system as stated here[1]. The mechanism that's going to be implemented to PiSi would evolve in terms of needs and PiSi structure.. and that's my proposal for the situation. any comments and reviews are welcomed. serdar [1] http://wiki.debian.org/SecureApt > Necmettin > _______________________________________________ > Gsoc mailing list > Gsoc at pardus.org.tr > http://liste.pardus.org.tr/mailman/listinfo/gsoc > From necmettin.begiter at gmail.com Fri Apr 18 05:05:59 2008 From: necmettin.begiter at gmail.com (Necmettin Begiter) Date: Fri, 18 Apr 2008 05:05:59 +0300 Subject: [Gsoc] A proposal about package signing/verification In-Reply-To: <4807ED76.8080907@cclub.metu.edu.tr> References: <3787dfa80804171504j312f24b6x5278da815c044d6f@mail.gmail.com> <4807ED76.8080907@cclub.metu.edu.tr> Message-ID: <3787dfa80804171905u115315f4w4c16cd45ff75d77a@mail.gmail.com> 2008/4/18, Serdar Dalgic : As far as I know, packages in Pardus do not include themselves' SHA1 or MD5 sums. Included in the pspec.xml is the SHA1 sum of the .tar.gz/.zip/.whatever (the actual package, not the container (the .pisi file)), and the pisi-index.xml file is basically a container for all the pspec.xml files in the repository, which means it does not include SHA1 or MD5 sums of the .pisi files either. The .pisi file is a container for the pspec.xml, translations.xml, files/*, and the actual package, which makes it just a shell AFAIK. When the user tries to install a .pisi file (either manually or through the 200x or contrib repositories), PiSi could easily get a MD5-or-SHA1 sum of the .pisi file and check it against the value in the database table if the system is online. On the database side, package maintainers (of the 200x and contrib repositories or of any other repository) would not have to do anything for this system to work. The system would add/update the MD5 or SHA1 sum of the new/updated .pisi packages automatically, once it learns that any one of the repositories has updated its index. > > So when somebody tries to install a package, pisi will check whether the > release files match and signed with distribution key; otherwise tell the > user that the packages s/he is trying to install may harm his/her system, > but also pisi gives the chance to continue.. User may have the chance to > keep on installing the "unsigned" package, but pisi freaks out on every step > (or one in two steps =) ) that's a little bit "fork" of debian's apt-secure > system as stated here[1]. The mechanism that's going to be implemented to > PiSi would evolve in terms of needs and PiSi structure.. > > and that's my proposal for the situation. > > any comments and reviews are welcomed. > > serdar > > [1] http://wiki.debian.org/SecureApt Here is a short criticism of Debian's SecureApt system (I am not a security professional but I will not confide in it just because Debian said so, and I believe the package signing mechanism of Debian is a little bit too limited): 1. Keeping the MD5 sums in the Release file is logical as long as all the repositories and packages are in your reach/control. The Release file is updated whenever a package is updated, and once developers start creating packages outside the "accepted" sources (devel-200x-contrib repositories in our case), the Release file, thus the MD5 sums and gpg keys, is/are out of reach for anybody but the packager/developer/repository owner. 2. The package management system not asking anything (because the definitions needed are already installed to the local system) to the official package signatures center (that would be the database table in my proposal) decreases the "amount" of security if I may say so. 3. In Debian's SecureApt system, a developer can have his/her own secure apt repository; all the signatures and sums are provided by that very developer, which means the distribution "authorities" have no control whatsoever over what that developer provides (both as a package and as a control mechanism (signatures/keys/sums)). The disadvantage this creates comes from the fact that being signed and being secure are two *very* different things. Apt the application is secure, the package is signed, but that's all, the packages are not secure. 4. SecureApt, in its current form, tries only to make sure that there has been no intervention in the process of package download; it is simply like using the HTTPS protocol in place of the HTTP protocol. Long story short: I believe Pardus project will in a near future encourage (at least not discourage) .pisi packages not in the current repositories (200x and contrib). Debian's SecureApt assumes safety as long as the maintainer of a repository or package knows how to take md5 sums and how to gpg-sign something. This is not the way to security. IMHO, a "secure package" is secure as long as it is approved by both users/ developers/ maintainers/ packagers. Debian's current mechanism makes "safe to download" packages, not "safe to install" packages. That is why I propose of a database table that is controlled by official Pardus developers or someone who has authority either officially or not. Even shorter: MD5 sums and signatures/ keys must be controllable officially, not locally. So, it appears to me, what we need might be not a package signing mechanism but a package verification mechanism. Necmettin From ygokirmak at gmail.com Fri Apr 18 09:17:38 2008 From: ygokirmak at gmail.com (yavuz gokirmak) Date: Fri, 18 Apr 2008 09:17:38 +0300 Subject: [Gsoc] A proposal about package signing/verification In-Reply-To: <3787dfa80804171905u115315f4w4c16cd45ff75d77a@mail.gmail.com> References: <3787dfa80804171504j312f24b6x5278da815c044d6f@mail.gmail.com> <4807ED76.8080907@cclub.metu.edu.tr> <3787dfa80804171905u115315f4w4c16cd45ff75d77a@mail.gmail.com> Message-ID: <6a825d550804172317r71eda950o4658b0320af8d514@mail.gmail.com> Necmettin, I may be wrong, here is my comment; Assume you have a package sum and you want to verify it from a database. Don't forget the unsecurity of the communication channels. You use an unsecure channel in order to get trusted md5 from database. Some eavesdropper can change the md5 value on air and send you the md5 of the file you get. And thus you verify the wrong package. I think public key cryptography still needed. Because packager signs the package with his/her private key, and sign can not be changed on air. Because corresponding public key verifes the sign, any changed sign can be detected.. yavuz.... On 18/04/2008, Necmettin Begiter wrote: > > 2008/4/18, Serdar Dalgic : > > As far as I know, packages in Pardus do not include themselves' SHA1 > or MD5 sums. Included in the pspec.xml is the SHA1 sum of the > .tar.gz/.zip/.whatever (the actual package, not the container (the > .pisi file)), and the pisi-index.xml file is basically a container for > all the pspec.xml files in the repository, which means it does not > include SHA1 or MD5 sums of the .pisi files either. The .pisi file is > a container for the pspec.xml, translations.xml, files/*, and the > actual package, which makes it just a shell AFAIK. > > When the user tries to install a .pisi file (either manually or > through the 200x or contrib repositories), PiSi could easily get a > MD5-or-SHA1 sum of the .pisi file and check it against the value in > the database table if the system is online. > > On the database side, package maintainers (of the 200x and contrib > repositories or of any other repository) would not have to do anything > for this system to work. The system would add/update the MD5 or SHA1 > sum of the new/updated .pisi packages automatically, once it learns > that any one of the repositories has updated its index. > > > > > > So when somebody tries to install a package, pisi will check whether > the > > release files match and signed with distribution key; otherwise tell the > > user that the packages s/he is trying to install may harm his/her > system, > > but also pisi gives the chance to continue.. User may have the chance to > > keep on installing the "unsigned" package, but pisi freaks out on every > step > > (or one in two steps =) ) that's a little bit "fork" of debian's > apt-secure > > system as stated here[1]. The mechanism that's going to be implemented > to > > PiSi would evolve in terms of needs and PiSi structure.. > > > > and that's my proposal for the situation. > > > > any comments and reviews are welcomed. > > > > serdar > > > > [1] http://wiki.debian.org/SecureApt > > > Here is a short criticism of Debian's SecureApt system (I am not a > security professional but I will not confide in it just because Debian > said so, and I believe the package signing mechanism of Debian is a > little bit too limited): > > 1. Keeping the MD5 sums in the Release file is logical as long as all > the repositories and packages are in your reach/control. The Release > file is updated whenever a package is updated, and once developers > start creating packages outside the "accepted" sources > (devel-200x-contrib repositories in our case), the Release file, thus > the MD5 sums and gpg keys, is/are out of reach for anybody but the > packager/developer/repository owner. > > 2. The package management system not asking anything (because the > definitions needed are already installed to the local system) to the > official package signatures center (that would be the database table > in my proposal) decreases the "amount" of security if I may say so. > > 3. In Debian's SecureApt system, a developer can have his/her own > secure apt repository; all the signatures and sums are provided by > that very developer, which means the distribution "authorities" have > no control whatsoever over what that developer provides (both as a > package and as a control mechanism (signatures/keys/sums)). The > disadvantage this creates comes from the fact that being signed and > being secure are two *very* different things. Apt the application is > secure, the package is signed, but that's all, the packages are not > secure. > > 4. SecureApt, in its current form, tries only to make sure that there > has been no intervention in the process of package download; it is > simply like using the HTTPS protocol in place of the HTTP protocol. > > Long story short: I believe Pardus project will in a near future > encourage (at least not discourage) .pisi packages not in the current > repositories (200x and contrib). Debian's SecureApt assumes safety as > long as the maintainer of a repository or package knows how to take > md5 sums and how to gpg-sign something. This is not the way to > security. IMHO, a "secure package" is secure as long as it is approved > by both users/ developers/ maintainers/ packagers. Debian's current > mechanism makes "safe to download" packages, not "safe to install" > packages. That is why I propose of a database table that is controlled > by official Pardus developers or someone who has authority either > officially or not. > > Even shorter: MD5 sums and signatures/ keys must be controllable > officially, not locally. > > So, it appears to me, what we need might be not a package signing > mechanism but a package verification mechanism. > > > Necmettin > _______________________________________________ > Gsoc mailing list > Gsoc at pardus.org.tr > http://liste.pardus.org.tr/mailman/listinfo/gsoc > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://liste.pardus.org.tr/gsoc/attachments/20080418/151aef8e/attachment-0001.htm From gurer at pardus.org.tr Fri Apr 18 11:55:17 2008 From: gurer at pardus.org.tr (=?iso-8859-1?q?G=FCrer_=D6zen?=) Date: Fri, 18 Apr 2008 11:55:17 +0300 Subject: [Gsoc] A proposal about package signing/verification In-Reply-To: <3787dfa80804171905u115315f4w4c16cd45ff75d77a@mail.gmail.com> References: <3787dfa80804171504j312f24b6x5278da815c044d6f@mail.gmail.com> <4807ED76.8080907@cclub.metu.edu.tr> <3787dfa80804171905u115315f4w4c16cd45ff75d77a@mail.gmail.com> Message-ID: <200804181155.18086.gurer@pardus.org.tr> On Friday 18 April 2008 05:05:59 Necmettin Begiter wrote: > .pisi file)), and the pisi-index.xml file is basically a container for > all the pspec.xml files in the repository, which means it does not > include SHA1 or MD5 sums of the .pisi files either. Have you actually checked inside the pisi-index.xml file? It doesn't contain all the pspec.xml, just necessary parts for installation, plus the extra information like installed size, etc. And of course package hash is there. But this simple scheme is only a little bit useful. You need to handle non-repo packages and no internet connection situations, etc. There is a ton of discussion of this in pardus developers list, and even a spec document somewhere in the wiki. There is also a previous attempt at http://svn.pardus.org.tr/uludag/trunk/staj-projeleri/imzaci/ You definitely need a much better understanding of pisi and cryptography before tackling this problem.