Re: Audit of Debian/Ubuntu for unfixed vulnerabilities because of embedded code copies
On Mon, Jul 02, 2012 at 07:59:26PM +0200, Petter Reinholdtsen wrote: [Silvio Cesare] I recently ran the tool and cross referenced identified code copies with Debian's security tracking of affected packages by CVE. I did this for all CVEs in 2010, 2011, and 2012. This sound like a job that could become a bit easier if we tagged Debian packages with the CPE ids assosiated with CVEs, to make it easier to figure out which Debian package are affected by a given CVE. Are you aware of my proposal to do this, mentioned on debian-security and also drafted on URL: http://wiki.debian.org/CPEtagPackagesDep ? -- Happy hacking Petter Reinholdtsen Has there been any progress with this project? I am glad to help if there is something I can do? This is needed in my opinion. - Henri Salo -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120929202243.ga12...@kludge.henri.nerv.fi
Should every package belong to a team ?
overview == about teams - I hope that one day every package shall belong to one or more team. So I propose that first every package which is taged orphaned,rfa, rfh shall belong to at least one team (different from QA) about complexity I think it could be interesting if each package could contain information about its complexity. It would be easier for people wanting to maintain an easy package to find one. So hopefully, it would attract new maintainers. The project could have a snapshot of its global complexity. my response == my previous proposition --- http://lists.debian.org/debian-devel/2012/03/msg00768.html followed by -- http://lists.debian.org/debian-devel/2012/03/msg00794.html -- If I need help on my package, why should it belong to a team when I file a RFH? If every packages which are taged orphaned,rfa or rfh, belonged to a team, each team could have a page with the list of all the packages needing some attention. So that the people who have the more chance to be interested in the package would be better informed. Someone interested to join a team could go to this page and find easily some easy packages to maintain. -- That's something that is incredibly subjective, I suggest that information about the difficulty of the package would be automatically generated when you build the package. So that it won't be subjective. Information about the langage(s) should also be included. -- bound to change as things arise The complexity information would be relevant for one build and would be updated at each upload. So, if after some time, the package requires custom rules, the complexity information would change. We would also have an history of the complexity of the package. The description of the difficulty of the package could/should be in the policy and could change, if needed. -- and of limited utility I have made a proposition about how the information could be displayed. If everybody think it has no utility, it won't be implemented. -- Henri LE FOLL
summer of code 2013 proposal
My first proposal can be found in : http://lists.debian.org/debian-devel/2012/03/msg00536.html I believe that the .dsc file of a package is generated automatically. I think that some information should be added to it. A Team field should be added to debian/control. (and also to the .dsc) === - I hope every package will one day belong to a team. - I think that each package in wnpp or rfa or rfh should belong to a team (other than QA). - This field could be optional before packages have to belong to a team. A Package difficulty field should be added to the .dsc. = - Some information about the difficulty to maintain the package can be automacally extracted from the source package and added to the dsc file. - this information could be then be seen in the wnpp mail, the PTS, UDD. As I don't know how to implement those changes, I suggest to create a project for the 2013 summer of code. Question = I am wrong in saying that information like : - a source package generates only one binary package - debian/rules is trivial. can be extracted automatically ? Henri P.S. Here is the an quotation from http://lists.debian.org/debian-devel/2012/03/msg00536.html -- automatically generated information about the difficulty to maintain the package = Three or more characters which could easily show the difficulty to maintain the package. AA0 for simple ones. This information should be generated automatically. 1. about the source package A : a source package generates only one binary package B : a source package generates multiple binary package C : a source package contains multiple upstream source. D : used for D-I (udeb) E : a library F : a daemon G : part of the kernel 2. about the conffiles and the maintainer script --- A : no modification from d-h B : only one file like copyright or control need attention E : non trivial maintainer script F : very difficult maintainer script. 3. if the package need to follow some sub-policy - O : none A : java B : perl C : python -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f6da1ef.3080...@lefoll.eu
adding information to wnpp
Hello I don't know a to maintain a package, and I would be interested to maintain a package I use every day. First I need to learn how to maintain an easy package. But I don't know how to find one. Question *** Is it possible to sort (and find) packages by the difficulty of its maintainance ? proposition ** If every package could contain information about the difficulty of its maintainance, - Every week on debian-devel the mail about Work-Needing and Prospective Packages could show this information. - The PTS could display this information in its general section - UDD could order and find packages by difficulty. Here are the informations I think could be usefull in the wnpp mail (and in the PTS when it is not already there) 1. The name of the team the package belongs to. == - I hope every package will one day belong to a team. - I think that each package in wnpp or rfa or rfh should belong to a team (other than QA). 2. the langages you need to know to maintain the package = 3. an automatically generated information about the difficulty to maintain the package == Three or more characters which could easily show the difficulty to maintain the package. AA0 for simple ones. This information should be generated automatically. 3.1 about the source package A : a source package generates one binary package B : a source package generates multiple binary package C : a source package contains multiple upstream source. D : used for D-I (udeb) E : a library F : a daemon G : part of the kernel 3.2 about the conffiles and the maintainer script --- A : no modification from d-h B : only one file like copyright or control need attention E : non trivial maintainer script F : very difficult maintainer script. 3.3 if the package need to follow some sub-policy - O : none A : java B : perl C : python -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f65f777.4070...@lefoll.eu
simple Debian package information in the wiki
Hi Stéphane, I have just created some pages on the wiki : http://wiki.debian.org/Packaging/Minimal (for empty packages) http://wiki.debian.org/Packaging/Trivial (for a pdf file) http://wiki.debian.org/Packaging I am interested to have feed back on it Thanks Henri Le Foll -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e5e26a1.4060...@lefoll.eu
Re: simple Debian package information in the wiki
First, to close the subject on debian-devel, I have sent this mail also to debian-mentors. please reply to debian-mentors. after this mail http://lists.debian.org/debian-devel/2011/08/msg00742.html I have put on the wiki some of my documentation about packaging. After some replies on debian-devel,I have rewritten the pages on the wiki to explain equivs-build. http://wiki.debian.org/Packaging/Minimal (for empty packages) http://wiki.debian.org/Packaging/Trivial (for package with files) You can also look at http://wiki.debian.org/Packaging I agree that http://wiki.debian.org/IntroDebianPackaging and the packaging-tutorial are good documentations. I work to attract people attention on them. I am still interested to have feed back on my modifications Thanks Henri Le Foll P.S. : please reply to debian-mentors. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e5e765f.6090...@lefoll.eu
add in pts : a link to upstream bts
In the PTS there is a link to the upstream mainpage. Is it possible to have also a link to the uptream bug tracking system if it exists. Cheers Henri LE FOLL -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d77d735.4090...@lefoll.eu
Re: Handling of (inactive) Debian Accounts
I read the mail but I'm not active Henri begin:vcard fn:Henri Auge n:Auge;Henri org;quoted-printable:Lyc=C3=A9e G Crampe Aire/Adour adr;dom:;;;Aire sur Adour;;40800 email;internet:[EMAIL PROTECTED] title:enseignant STS IRIS version:2.1 end:vcard
Request for package: Midgard
Greetings! First, I guess it would be a good idea to introduce me and the project I'm talking about. I am working as a Webmaster for a finnish IT company. Our Web Team does all of the development using Free Software tools, and also participates actively in some projects in our field, most important of these being the Midgard project. Midgard is a freely-available web application server based on PHP3 (http://www.midgard-project.org). Now, as I use Debian boxes at work, I have been thinking on making a Debianized version of Midgard so that it would work better for users of this very nice distribution. However, after studying the matter for a while, I understand that while I could easily get Midgard packaged and make it available, I still wouldn't propably have enough time to fulfill the responsibilities of a Debian Developer properly. Because of this I am asking you whether there would be interest in some of you to work on creating an maintaining the Debian packages for this application server suite. The Midgard Project is evolving quite fast and new versions are popping up every few weeks. It is licensed under LGPL with example code in it distributed under the X Consortium license. This would make it suitable for the main branch. However, as it depends on MySQL (non-free, I guess) at this point it should propably be placed in contrib. We are looking to add support for other databases and this problem should disappear sometime during June. If you are interested in the project, please contact me and I'll be happy to help you with getting the project started and working. Thanks in advance! /Bergie -- -- Henri Bergius -- +358 40 525 1334 -- [EMAIL PROTECTED] -- http://www.iki.fi/Henri.Bergius
