Menu
▾
▴
devil-linux-develop — developer discussions
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(55) |
Oct
(44) |
Nov
(156) |
Dec
(123) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(130) |
Feb
(156) |
Mar
(162) |
Apr
(171) |
May
(97) |
Jun
(127) |
Jul
(58) |
Aug
(81) |
Sep
(86) |
Oct
(45) |
Nov
(41) |
Dec
(84) |
| 2003 |
Jan
(71) |
Feb
(87) |
Mar
(133) |
Apr
(152) |
May
(151) |
Jun
(232) |
Jul
(320) |
Aug
(237) |
Sep
(271) |
Oct
(536) |
Nov
(301) |
Dec
(393) |
| 2004 |
Jan
(393) |
Feb
(184) |
Mar
(314) |
Apr
(225) |
May
(139) |
Jun
(77) |
Jul
(87) |
Aug
(75) |
Sep
(139) |
Oct
(50) |
Nov
(8) |
Dec
(28) |
| 2005 |
Jan
(66) |
Feb
(63) |
Mar
(14) |
Apr
(14) |
May
(8) |
Jun
(23) |
Jul
(21) |
Aug
(6) |
Sep
(29) |
Oct
(55) |
Nov
(38) |
Dec
(8) |
| 2006 |
Jan
(5) |
Feb
(10) |
Mar
(1) |
Apr
(15) |
May
(32) |
Jun
(44) |
Jul
(11) |
Aug
(8) |
Sep
(9) |
Oct
(14) |
Nov
(4) |
Dec
(3) |
| 2007 |
Jan
(3) |
Feb
(3) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
(35) |
Aug
(49) |
Sep
(8) |
Oct
(42) |
Nov
(44) |
Dec
(7) |
| 2008 |
Jan
(2) |
Feb
(7) |
Mar
(8) |
Apr
(80) |
May
(74) |
Jun
(29) |
Jul
(5) |
Aug
(7) |
Sep
(6) |
Oct
(1) |
Nov
|
Dec
|
| 2009 |
Jan
(8) |
Feb
(19) |
Mar
(3) |
Apr
(24) |
May
(22) |
Jun
(23) |
Jul
(8) |
Aug
(23) |
Sep
(8) |
Oct
(27) |
Nov
(52) |
Dec
(27) |
| 2010 |
Jan
(36) |
Feb
(29) |
Mar
(17) |
Apr
(28) |
May
(21) |
Jun
(4) |
Jul
|
Aug
(28) |
Sep
(18) |
Oct
(6) |
Nov
(34) |
Dec
(16) |
| 2011 |
Jan
(18) |
Feb
(12) |
Mar
|
Apr
|
May
(9) |
Jun
(1) |
Jul
(5) |
Aug
(5) |
Sep
(7) |
Oct
(16) |
Nov
(26) |
Dec
(17) |
| 2012 |
Jan
(6) |
Feb
(34) |
Mar
(52) |
Apr
(10) |
May
(3) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
(4) |
Nov
(1) |
Dec
(4) |
| 2013 |
Jan
(5) |
Feb
|
Mar
|
Apr
(5) |
May
(4) |
Jun
|
Jul
|
Aug
(14) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
(2) |
Mar
(5) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
(11) |
| 2015 |
Jan
(5) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
(1) |
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Heiko Z. <he...@zu...> - 2004-01-13 12:35:17
|
Oliver Jehle wrote: > getgrouplist patch... see in the cve.mitre.. > applies .... > > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0689 > > another one is for the netlink interface .. but have to check it > first, didn't apply with my sources... but only to have them on the > mailing list :-) and not forgot... > > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0859 I had to remove the ifaddrs patch, it didn't apply. Can you check on this? Heiko |
|
From: Oliver J. <oli...@mo...> - 2004-01-13 09:16:35
|
please update version to 4.5.1 from http://prdownloads.sourceforge.net/strace/strace-4.5.1.tar.bz2?download patch from gentoo tree... adjusts includes for 2.6 |
|
From: Oliver J. <oli...@mo...> - 2004-01-13 09:08:06
|
changed include header from gentoo tree... (original from debian)... |
|
From: Oliver J. <oli...@mo...> - 2004-01-13 08:56:39
|
adjust headers .. from the gentoo tree |
|
From: Oliver J. <oli...@mo...> - 2004-01-13 07:59:43
|
include 2.4 headers for compile.... only a workaround... until a new sysklogd with adapted sources will be available... |
|
From: Oliver J. <oli...@mo...> - 2004-01-13 07:56:12
|
thats better then patching the old one .-) thx.. On Tue, 2004-01-13 at 03:23, Heiko Zuerker wrote: > Friedrich Lobenstock wrote: > > > Can you please give more background info about this problem. I think > > such a patch might make more troubles in the long run as it looks > > very cosmetic to me. > > > > Could you please try to get a more official patch for that problem? > > > > > It's not a big deal, there's a 1.35 testing version available, which > compiles just fine. > > I will upload all the changes shortly. > > Heiko > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Perforce Software. > Perforce is the Fast Software Configuration Management System offering > advanced branching capabilities and atomic changes on 50+ platforms. > Free Eval! http://www.perforce.com/perforce/loadprog.html > _______________________________________________ > Devil-linux-develop mailing list > Dev...@li... > https://lists.sourceforge.net/lists/listinfo/devil-linux-develop |
|
From: Oliver J. <oli...@mo...> - 2004-01-13 07:25:02
|
util-linux-2.12-kernel-2.6 gentoo patch for 2.6 patching the headers excluded crypto loop patch for 2.6 |
|
From: Oliver J. <oli...@mo...> - 2004-01-13 06:41:51
|
not needed in 2.6.. already included... and e1000 not build... |
|
From: Oliver J. <oli...@mo...> - 2004-01-13 06:04:13
|
The problem was, that SCSI_DISK_MAJOR didn't exists any more...
and when you look on it... but i will look if i find an official
patch of it...
if you look what it does, its only a check if its the full device
or not... and the pach removes the check if its a disk or cdrom, now it
works for all scsi devices.. have fun to use e2fs on a tape ;-)
try to compile to original packages with includes 2.6 and you will see
the problem...
there are other packages make also a lot of problems... because they
are not ported to 2.6 and the includes have changed....
On Mon, 2004-01-12 at 22:00, Friedrich Lobenstock wrote:
> Hi Oliver!
>
> Oliver Jehle wrote on 12.01.2004 17:15 MET:
> > e2fsprogs didnt compile ... problem with defines
> >
> > ------------------------------------------------------------------------
> >
> > --- e2fsprogs-old/misc/util.c Sat May 3 15:46:47 2003
> > +++ e2fsprogs-1.34/misc/util.c Tue Sep 30 06:56:11 2003
> > @@ -108,13 +108,8 @@
> > #define MAJOR(dev) ((dev)>>8)
> > #define MINOR(dev) ((dev) & 0xff)
> > #endif
> > -#ifndef SCSI_BLK_MAJOR
> > -#define SCSI_BLK_MAJOR(M) ((M) == SCSI_DISK_MAJOR || (M) == SCSI_CDROM_MAJOR)
> > -#endif
> > - if (((MAJOR(s.st_rdev) == HD_MAJOR &&
> > - MINOR(s.st_rdev)%64 == 0) ||
> > - (SCSI_BLK_MAJOR(MAJOR(s.st_rdev)) &&
> > - MINOR(s.st_rdev)%16 == 0))) {
> > + if (MAJOR(s.st_rdev) == HD_MAJOR &&
> > + MINOR(s.st_rdev)%64 == 0) {
> > printf(_("%s is entire device, not just one partition!\n"),
> > device);
> > proceed_question();
>
> Can you please give more background info about this problem. I think
> such a patch might make more troubles in the long run as it looks
> very cosmetic to me.
>
> Could you please try to get a more official patch for that problem?
|
|
From: Heiko Z. <he...@zu...> - 2004-01-13 02:46:35
|
Friedrich Lobenstock wrote: > Heiko Zuerker wrote on 13.01.2004 03:23 MET: > >> Friedrich Lobenstock wrote: >> >>> Can you please give more background info about this problem. I think >>> such a patch might make more troubles in the long run as it looks >>> very cosmetic to me. >>> >>> Could you please try to get a more official patch for that problem? >>> >> >> >> It's not a big deal, there's a 1.35 testing version available, which >> compiles just fine. > > > Hopefully with 2.4 too. I can tell you tomorrow. I need to recompile everything anyway, to see if I broke anything. Heiko |
|
From: Friedrich L. <fl...@fl...> - 2004-01-13 02:29:46
|
Heiko Zuerker wrote on 13.01.2004 03:23 MET: > Friedrich Lobenstock wrote: > >> Can you please give more background info about this problem. I think >> such a patch might make more troubles in the long run as it looks >> very cosmetic to me. >> >> Could you please try to get a more official patch for that problem? >> > > > It's not a big deal, there's a 1.35 testing version available, which > compiles just fine. Hopefully with 2.4 too. -- MfG / Regards Friedrich Lobenstock ____________________________________________________________________ Friedrich Lobenstock Linux Services Lobenstock URL: http://www.lsl.at/ Email: fl...@fl... ____________________________________________________________________ |
|
From: Heiko Z. <he...@zu...> - 2004-01-13 02:26:55
|
Friedrich Lobenstock wrote: > Can you please give more background info about this problem. I think > such a patch might make more troubles in the long run as it looks > very cosmetic to me. > > Could you please try to get a more official patch for that problem? > It's not a big deal, there's a 1.35 testing version available, which compiles just fine. I will upload all the changes shortly. Heiko |
|
From: Heiko Z. <he...@zu...> - 2004-01-13 02:26:55
|
Oliver Jehle wrote: > use the new debian patch set instead of 1.60.8.diff.gz.. fix problem > for 2.6 and x25 > > DONE Heiko |
|
From: <hzu...@ra...> - 2004-01-12 21:28:41
|
On 01/12/2004 04:16:40 PM Friedrich Lobenstock wrote: >Bruce Smith wrote on 12.01.2004 22:01 MET: >>>Usually I set everything to 644 ... >> >> It would be easier if we got rid of the perl-ext subdirectory, >> then we could do a "chmod 644 *" after every upload. > >A change of the default settings on the server might also help. I asked Gunther a few times to do this, he did something... Heiko |
|
From: <hzu...@ra...> - 2004-01-12 21:28:40
|
On 01/12/2004 04:01:11 PM Bruce Smith wrote: >> Usually I set everything to 644 ... > >It would be easier if we got rid of the perl-ext subdirectory, >then we could do a "chmod 644 *" after every upload. We could change it, so those files are all in a .tar file Heiko |
|
From: Friedrich L. <fl...@fl...> - 2004-01-12 21:16:54
|
Bruce Smith wrote on 12.01.2004 22:01 MET: >>Usually I set everything to 644 ... > > It would be easier if we got rid of the perl-ext subdirectory, > then we could do a "chmod 644 *" after every upload. A change of the default settings on the server might also help. -- MfG / Regards Friedrich Lobenstock ____________________________________________________________________ Friedrich Lobenstock Linux Services Lobenstock URL: http://www.lsl.at/ Email: fl...@fl... ____________________________________________________________________ |
|
From: Bruce S. <bw...@ar...> - 2004-01-12 21:01:13
|
> Usually I set everything to 644 ... It would be easier if we got rid of the perl-ext subdirectory, then we could do a "chmod 644 *" after every upload. - BS |
|
From: Friedrich L. <fl...@fl...> - 2004-01-12 21:00:56
|
Hi Oliver!
Oliver Jehle wrote on 12.01.2004 17:15 MET:
> e2fsprogs didnt compile ... problem with defines
>
> ------------------------------------------------------------------------
>
> --- e2fsprogs-old/misc/util.c Sat May 3 15:46:47 2003
> +++ e2fsprogs-1.34/misc/util.c Tue Sep 30 06:56:11 2003
> @@ -108,13 +108,8 @@
> #define MAJOR(dev) ((dev)>>8)
> #define MINOR(dev) ((dev) & 0xff)
> #endif
> -#ifndef SCSI_BLK_MAJOR
> -#define SCSI_BLK_MAJOR(M) ((M) == SCSI_DISK_MAJOR || (M) == SCSI_CDROM_MAJOR)
> -#endif
> - if (((MAJOR(s.st_rdev) == HD_MAJOR &&
> - MINOR(s.st_rdev)%64 == 0) ||
> - (SCSI_BLK_MAJOR(MAJOR(s.st_rdev)) &&
> - MINOR(s.st_rdev)%16 == 0))) {
> + if (MAJOR(s.st_rdev) == HD_MAJOR &&
> + MINOR(s.st_rdev)%64 == 0) {
> printf(_("%s is entire device, not just one partition!\n"),
> device);
> proceed_question();
Can you please give more background info about this problem. I think
such a patch might make more troubles in the long run as it looks
very cosmetic to me.
Could you please try to get a more official patch for that problem?
--
MfG / Regards
Friedrich Lobenstock
____________________________________________________________________
Friedrich Lobenstock Linux Services Lobenstock
URL: http://www.lsl.at/ Email: fl...@fl...
____________________________________________________________________
|
|
From: <hzu...@ra...> - 2004-01-12 20:56:45
|
On 01/12/2004 10:35:38 AM hzuerker wrote: >On 01/12/2004 09:52:03 AM Oliver Jehle wrote: >>whats the roblem with the initrd ??? i think evms.sourceforge.net use >it >>for having root-evms volumes or the fedora / redhat distribution.. > >I don't know yet. Yesterday I had the first time the Kernel compiling >and >it refused to mount the initrd. >One problem is that the support for having the initrd as cramfs, but >that >solved. >At the moment it doesn't even like the ext2 version. > >But as I said I'm in an early stage, so that doesn't mean anything. The system is booting now. Module support is missing and there are a few other error messages during bootup. For now, Ext2 has to be selected as InitRD FS in menuconfig. Oh yes: I first compiled the system for Kernel 2.4 with no extra options selected in menuconfig, then switched to 2.6. After that: rm tmp/.done_build_linux make clean build install iso Heiko |
|
From: <hzu...@ra...> - 2004-01-12 20:56:45
|
On 01/12/2004 03:39:00 PM Bruce Smith wrote: >UPDATING from Devil-Linux FTP-Server Frankfurt (M)/Germany >Transferring file `linux-2.6.1.tar.bz2' >mirror: Access failed: 550 linux-2.6.1.tar.bz2: Permission denied > >I hope you wanted that file to be downloadable now, I did a chmod on it. >There was another file with 666 permissions on the server. Not good, >considering our discussion on security today. I fixed it too. Usually I set everything to 644, but I "quickly" uploaded that stuff yesterday... (It didn't happen for a while ;-) ) Heiko |
|
From: Bruce S. <bw...@ar...> - 2004-01-12 20:39:01
|
UPDATING from Devil-Linux FTP-Server Frankfurt (M)/Germany Transferring file `linux-2.6.1.tar.bz2' mirror: Access failed: 550 linux-2.6.1.tar.bz2: Permission denied I hope you wanted that file to be downloadable now, I did a chmod on it. There was another file with 666 permissions on the server. Not good, considering our discussion on security today. I fixed it too. - BS |
|
From: Friedrich L. <fl...@fl...> - 2004-01-12 19:48:46
|
Bruce Smith wrote on 12.01.2004 20:29 MET: > > How do we protect the lfssystem...tar file itself? > Someone could cause us real problems by changing that file. The same md5sum file signed. Then on the homepage we put up the info how to download the public keys that correspond to the signing keys. The keys can also be checked-in into CVS I think. So then a very curiouse person will get the public key from cvs and from a pgp keyserver to be sure to have the correct one. -- MfG / Regards Friedrich Lobenstock ____________________________________________________________________ Friedrich Lobenstock Linux Services Lobenstock URL: http://www.lsl.at/ Email: fl...@fl... ____________________________________________________________________ |
|
From: Bruce S. <bw...@ar...> - 2004-01-12 19:29:11
|
> > Or on the host Linux, especially since you can't download the source > > from within the LFS chroot anyway. > > You can for sure download chrooted to the lfs system. You probably > have to copy your /etc/resolv.conf to corresponding directory of the > lfs system. Done that for a long time. You're right, cool! :-) I've never bothered to try and get it working. > If we have it in the lfs system everybody has for sure the > same environment. How do we protect the lfssystem...tar file itself? Someone could cause us real problems by changing that file. - BS |
|
From: Friedrich L. <fl...@fl...> - 2004-01-12 19:20:49
|
hzu...@ra... wrote on 12.01.2004 20:01 MET: > On 01/12/2004 12:39:01 PM Friedrich Lobenstock wrote: > >>Bruce Smith wrote on 12.01.2004 17:49 MET: >> >>>>>>>another questions, are there plans to sign the source packages ???? >>>>>>>only a litte but important thing :-) >>>>>> >>>>>>Maybe we should at least do md5sums automatically in the update >> >>script. >> >>>>>>That should be enough for now I think. >>>>> >>>>> >>>>>Good idea >>>> >>>>Already filed a feature request. >>>> >>>>I think the best way is that we create for eg. archive.tar.bz2 >>>>a file archive.tar.bz2.md5sum. This was we can easily automate >>>>the task of checking every file while at the same time decoupling >>>>it from one single ftp maintainer who would create on big md5sum >>>>file for all files. >>> >>> >>>While this is a great idea to ensure the downloads are good, it does >>>nothing to prevent what happened at Debian. If someone breaks into >> >>the >> >>>FTP site, they can easily create a new md5sum file after they change >> >>the >> >>>source code. We really need some kind of a signed file to prevent >>>that. Or at least keep the md5sum files on a different server. >> >>Than every developer who can upload files to the ftp server needs >>to sign each md5sum file he uploads, right?. >> >>That would mean GPG needs to be installed in the lfs system right > >>from the beginning. The kexring can't be in CVS either, so that > >>would mean at start a developer has to initialize the keyring with >>all the GPG/PGP public certificates. It always get's more >>complicated... > > > GPG signing is just too much work, especially the handling of the private > key. > We can't put it in CVS, because otherwise everybody can sign the files..... Of course not, but we can put the keyrings with our public keys in there and also the trust database file. > What's about this simple idea: > we add a new file to the CVS repository with this format: > filename md5sum > > One line per source file. > When we upload a file to the FTP Server, we have to create the checksum and > update the file. > update_src checks the checksum and warns if it is wrong or missing. Then you have to update this file from CVS every time you get new sources. I would rather stay with the signed md5sum file per archive file. Your way is of course also possible, but I would than say that you have a second file which keeps the gpg signature of this file so we are really sure. -- MfG / Regards Friedrich Lobenstock ____________________________________________________________________ Friedrich Lobenstock Linux Services Lobenstock URL: http://www.lsl.at/ Email: fl...@fl... ____________________________________________________________________ |
|
From: Friedrich L. <fl...@fl...> - 2004-01-12 19:15:48
|
Bruce Smith wrote on 12.01.2004 19:29 MET: >>>While this is a great idea to ensure the downloads are good, it does >>>nothing to prevent what happened at Debian. If someone breaks into the >>>FTP site, they can easily create a new md5sum file after they change the >>>source code. We really need some kind of a signed file to prevent >>>that. Or at least keep the md5sum files on a different server. >> >>Than every developer who can upload files to the ftp server needs >>to sign each md5sum file he uploads, right?. > > > Probably be easier than signing the tar files. :-) > > >>That would mean GPG needs to be installed in the lfs system right >>from the beginning. > > > Or on the host Linux, especially since you can't download the source > from within the LFS chroot anyway. You can for sure download chrooted to the lfs system. You probably have to copy your /etc/resolv.conf to corresponding directory of the lfs system. Done that for a long time. So the only commands we need from the host Linux are basically chroot, cvs, diff and ssh. > We could make GPG required on the host Linux, like lftp. If we have it in the lfs system everybody has for sure the same environment. >>The kexring can't be in CVS either, > > > Why not? It's a different server. Different access/passwords, and > if someone changed it, we'd be notified by email on the commit list. Ok, good point, so lets put it there. >>so that would mean at start a developer has to initialize the keyring >>with all the GPG/PGP public certificates. > > > Maybe the keys could be installed on the local system once? > > Redhat does it something like that with their RPM's. You download the > keys once, which are installed on the local Redhat system. Then RPM > automatically checks the signatures when installing a RPM file. > > This is all just theory on my part, since I've never actually setup > anything like this. Feel free to blow holes in my ideas. If the keyring is in CVS do a checkout or update and then chrooted to the lfs system now you should be able to use gpg. -- MfG / Regards Friedrich Lobenstock ____________________________________________________________________ Friedrich Lobenstock Linux Services Lobenstock URL: http://www.lsl.at/ Email: fl...@fl... ____________________________________________________________________ |
35 messages has been excluded from this view by a project administrator.
