Re: qtpfsgui for Debian
Sune Vuorela wrote: On Tuesday 30 October 2007, Joey Schulze wrote: For a friend I've just installed qtpfsgui on etch and wonder if there are plans to include this package in sid-lenny already? Hi! We have currently no plans to package it, so you are most welcome to package it if you feel it should be in debian. I'm sorry, but I'd probably be the worst person maintaining a KDE-oriented package. Regards, Joey -- Life is a lot easier when you have someone to share it with. -- Sean Perry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325254: kdegraphics packages broken on sarge/powerpc because of kdelibs4 dependency
Adeodato Simó wrote: severity 325254 serious reassign 325254 kdegraphics,security.debian.org retitle 325254 kdegraphics 3.3.2-2sarge1/powerpc uninstallable because of dependency on kdelibs4 (= 4:3.3.2-6.2) notfound 325254 4:3.3.2-2 found 325254 4:3.3.2-2sarge1 thanks * Jochen Antesberger [Fri, 26 Aug 2005 19:25:32 -0500]: Package: kdegraphics Version: 4:3.3.2-2 Severity: important *** Please type your report below this line *** The security updates for the kdegraphics packages for Sarge on powerpc cannot be installed because they depend on kdelibs4 = 4:3.3.2-6.2 while only = 4:3.3.2-6.1 is available. ARGS. An advisory for kdelibs is pending but missing the mips build. Why the )*(#%$ does a KDE package depend on the exact Debian version of another KDE package? That should not be the case in the first place. I suppose the correct kdelibs4 package needs to be supplied by the security servers as well to allow the new packages to be installed and the security gap being closed on the powerpc architecture. Will happen soon. Regards, Joey -- No question is too silly to ask, but, of course, some are too silly to answer. -- Perl book Please always Cc to me when replying to me on the lists.
CAN-2005-1920: information leak in kate / kwrite
Hi, did you notice http://www.kde.org/info/security/advisory-20050718-1.txt? I'm building an update for sarge now. Can you tell me which version of the package will have the fix included in sid? Regards, Joey -- Long noun chains don't automatically imply security. -- Bruce Schneier Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
CAN-2005-0404: information leak in kmail
Please make sure a correction to this makes it into sarge. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0404 Reference: MLIST:[kmail-devel] 20050215 [Bug 96020] HTML Allows Spoofing of Emails Content Reference: URL:http://mail.kde.org/pipermail/kmail-devel/2005-February/015490.html Reference: MISC:http://bugs.kde.org/show_bug.cgi?id=96020 Reference: MISC:http://www.securiteam.com/unixfocus/5GP0B0AFFE.html Reference: URL:http://secunia.com/advisories/14925 Regards, Joey -- Those who don't understand Unix are condemned to reinvent it, poorly. Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#293754: kleopatra does not install
Package: kleopatra Version: 3.3.1-3 Tags: sid sarge Severity: serious The package should at least be installable when it is in the Debian archive, even if it is a contrib package. # apt-get install kleopatra Reading Package Lists... Done Building Dependency Tree... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. Since you only requested a single operation it is extremely likely that the package is simply not installable and a bug report against that package should be filed. The following information may help to resolve the situation: The following packages have unmet dependencies: kleopatra: Depends: gpgsm but it is not installable E: Broken packages There is no such package as gpgsm and it is not listed in permitted fake packages (/org/ftp.debian.org/testing/data/testing/FauxPackages). Regards, Joey -- Testing? What's that? If it compiles, it is good, if it boots up, it is perfect. Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#287201: [patch] KDE ftp kioslave applies to woody as well
Adeodato Simó wrote: * Martin Schulze [Thu, 06 Jan 2005 16:49:21 +0100]: Please . update the package in sid . mention the CVE id from the subject in the changelog . tell me the version number of the fixed package . use priority=high . no need to upload into sarge directly, except the version in sid is not meant to go into testing I recommend that you don't wait for the unstable package to be uploaded, since we need to hold it up until the latest kdebase and arts packages are built on all arches (#98 and #88 in the sparc queue, #18 and #14 in mipsel, the m68k buildd that picked kdebase is fast). I won't wait unless I get a notice. Of course, you may want to mail us just before the stable security update happens, in case we're ready to go then. Is there an ETA for it already? It depends how fast packages are built on our 11 architectures and if there are problems. For example, on i386 I just noticed: Checking kdelibs3_2.2.2-13.woody.13_i386.deb against stable ~~~ Files in second .deb but not in first - /usr/lib/libgmcop.la /usr/lib/libgmcop.so /usr/lib/libgmcop.so.0 /usr/lib/libgmcop.so.0.0.0 I have no idea where this library comes from. Regards, Joey -- There are lies, statistics and benchmarks. Please always Cc to me when replying to me on the lists.
Bug#287201: [patch] KDE ftp kioslave applies to woody as well
Moritz Muehlenhoff wrote:
Hi,
this applies to woody as well. Attached you can find the backported upstream
patch against 2.2.2. BTW, this is CAN-2004-1165.
Cheers,
Moritz
diff -Naur kdelibs-2.2.2.orig/kio/ftp/ftp.cc kdelibs-2.2.2/kio/ftp/ftp.cc
--- kdelibs-2.2.2.orig/kio/ftp/ftp.cc Wed Jan 5 12:29:07 2005
+++ kdelibs-2.2.2/kio/ftp/ftp.cc Wed Jan 5 12:28:25 2005
@@ -596,6 +596,14 @@
{
assert( sControl 0 );
+ if ( cmd.find( '\r' ) != -1 || cmd.find( '\n' ) != -1)
+ {
+kdWarning(7102) Invalid command received (contains CR or LF):
+ cmd.data() endl;
+error( ERR_UNSUPPORTED_ACTION, m_host );
+return false;
+ }
+
QCString buf = cmd;
buf += \r\n;
Thanks, that was on my agenda as well. Working on it now.
Please
. update the package in sid
. mention the CVE id from the subject in the changelog
. tell me the version number of the fixed package
. use priority=high
. no need to upload into sarge directly, except the version in
sid is not meant to go into testing
Regards,
Joey
--
Let's call it an accidental feature. -- Larry Wall
Bug#278173: kpdf: CAN-2004-0888: arbitrary code execution
Package: kpdf Version: 3.3.0-2 Severity: critical Tags: security, sid, sarge Please see DSA 573 http://www.kde.org/info/security/advisory-20041021-1.txt I can provide a patch for xpdf if that's required, contact me privately. Regards, Joey -- There are lies, statistics and benchmarks. Please always Cc to me when replying to me on the lists.
Bug#268016: [CAN-2004-0746] Konqueror Cross-Domain Cookie Injection
Package: konqueror Version: 3.2.3-1 Severity: grave Tags: security upstream sarge Web sites operating under the affected domains can set HTTP cookies in such a way that the Konqueror web browser will send them to all other web sites operating under the same domain. A malicious website can use this as part of a session fixation attack. See e.g. http://www.acros.si/papers/session_fixation.pdf Affected are all country specific secondary top level domains that use more than 2 characters in the secondary part of the domain name and that use a secondary part other than com, net, mil, org, gov, edu or int. Examples of affected domains are .ltd.uk, .plc.uk and .firm.in KDE versions up to KDE 3.2.3 inclusive. KDE 3.3 is not affected. There is 3.2.3-1 in sid for some architectures, but they will probably replaced soon by 3.3.0-1 which is said to be not vulnerable. Regards, Joey -- There are lies, statistics and benchmarks. Please always Cc to me when replying to me on the lists.
KDE Security Advisory: URI Handler Vulnerabilities
Hi, could you tell me which version of kdelibs, kdenetwork (or another package if another one is affected) fixes this problem in unstable? http://www.kde.org/info/security/advisory-20040517-1.txt If you apply the patch, please mention CAN-2004-0411 in the changelog file so we can easier track this security problem. Regards, Joey -- Reading is a lost art nowadays. -- Michael Weber
Re: KDE3 - Debian/experimental distribution proposal (was: yes i am alive ;)
Moin Ralf! Ralf Nolden wrote: well, as much as this would work out, someone has to do the work actually. And regarding the experimental distribution - that brings your work environment to a highly unstable state, not to speak about the packagers having to build the packages on this system. The experimental distribution is designed for exactly this: Store packages that are not yet suitable for unstable. Packages don't need to be uber-unstable to be uploaded to experimental, though. It could also be used as a staging area to store the packages before everything is sorted out so they can be uploaded into unstable properly. Another advantage of using experimental is that everything would already be in the Debian archive: overrides, package names for the BTS, files in the pool etc. pp. This would mean that these packages could already use the Debian package infrastructure, even though they are not yet part of unstable. However, I doubt that experimental is autobuilt, so it'll require manual attention. This will make it easer to upload all relevant packages into unstable afterwards. Now, let's please be reasonable about what can be done easily and what is desireable. Have a quick look at the current state: Please take into account that quick and easy solutions are often not good and promising solutions. Going the proper path, however, sounds much better to me and will probably be less painful for the future. The other thing is what version of Debian users want to run KDE on. I myself This is a completely different story, unfortunately. You'll have to separate two issues: unstable/sid and woody. Let's talk about woody first. The woody distribution was released in July and will stay stable until it will be removed from the Debian servers and moved to the Debian archive. Updates will address only security and very serious problems. KDE has no chance to get updated in woody except for security concerns (which will happen). However, no new version of KDE will be included in woody. This is nothing to worry about. This ensures that the stable distribution doesn't change too much during its lifetime. All installations and systems will more or less be the same. If you would like to provide newer KDE packages for woody, which would probably be a benefit from a users perspective, you'll need to bypass the Debian server. For this purpose, being able to add a line like deb http://debian.kde.org woody main to apt.sources, would probably the best and most logical solution (or switch the name to kde.debian.org/net). Addressing unstable should be the long-term goal for all KDE packages, since this will be the basis for the next stable distribution of Debian, which will be released in the future. Once all problems are sorted out, packages should be uploaded into the unstable distribution. Providing preliminary Debian packages on external resources will help developing packages for unstable. Using the experimental distribution of Debian will enable them to use the Debian infrastructure as well. My idea would be better to create a debian.kde.org website to collect all this information and to host a permanent official build on ftp.kde.org. That can be the releases as they are plus additional applications that are provided for those builds. We can sort those in into ftp if we like to, and that is the easiest way to provide people a one-liner for their sources.list to update regularly. Having a native source for additional information, howtos, guidelines etc. is always a benefit. If such documentation is rather static and less of a moving target and also dedicated for end-users, it may be worth considering the use of www.debian.org. This will automatically add translations and is the native source for information addressing Debian. To conclude and since this mail is already quite long, from a core developer's perspective I would like to see: 1. debian.kde.org or kde.debian.org store more recent packages for woody for those who would like to run a more recent version than the one which is supplied with woody. This could run on a debian.org host (e.g. klecker) or on a kde.org host, and would be an unofficial packges source. 2. In order to provide new packages for the unstable distribution I'd like to see the experimental distribution of Debian used, since this enables using the entire infrastructure of Debian except for the buildds. 3. Storing additional information on an easy to remember host like debian.kde.org or kde.debian.org is always good. However, it should probably be decided whether some information would also be suited for www.debian.org. Regards, Joey -- Every use of Linux is a proper use of Linux. -- Jon Maddog Hall Please always Cc to me when replying to me on the lists.
Re: KDE3 - Debian/experimental distribution proposal (was: yes i am alive ;)
ReMoin! Ralf Nolden wrote: Ralf Nolden wrote: well, as much as this would work out, someone has to do the work actually. And regarding the experimental distribution - that brings your work environment to a highly unstable state, not to speak about the packagers having to build the packages on this system. The experimental distribution is designed for exactly this: Store packages that are not yet suitable for unstable. Packages don't need to be uber-unstable to be uploaded to experimental, though. It could also be used as a staging area to store the packages before everything is sorted out so they can be uploaded into unstable properly. Yepp. Another advantage of using experimental is that everything would already be in the Debian archive: overrides, package names for the BTS, files in the pool etc. pp. This would mean that these packages could already use the Debian package infrastructure, even though they are not yet part of unstable. However, I doubt that experimental is autobuilt, so it'll require manual attention. That means more work than putting KDE into unstable I guess. No, it should be easier, once the packages have demonstrated their quality in experimental since the Debian infrastructure is already used. One thing that keeps new packages out of the archive is missing overrides lines. I'd expect that it is easier for the ftp people to copy overrides lines from experimental to unstable than creating new ones which requires thinking and considerations. Of course, it's more work than simply dumping the packages into a directory and not care about them anymore. However, that won't help very much anyway. This is a completely different story, unfortunately. Yes, understood. But I have to have a build for woody due to our customer demand (at credativ where I'm working now). So those builds are made anyway and are provided at the same time by KDE for woody users. I'm not speaking about updating KDE in woody. Copying these builds into a properly designed and apt-get'able area will probably be a benefit for many users. If you would like to provide newer KDE packages for woody, which would probably be a benefit from a users perspective, you'll need to bypass the Debian server. For this purpose, being able to add a line like deb http://debian.kde.org woody main to apt.sources, would probably the best and most logical solution (or switch the name to kde.debian.org/net). Yes, something like this. We'll have to go through the webserver stuff at KDE first or just use ftp.kde.org for that. I noticed that http://ftp.kde.org/ doesn't work, so you may want to add this in order to make the archive fully apt-get'able including the use of the http get method through web proxies. Having a native source for additional information, howtos, guidelines etc. is always a benefit. If such documentation is rather static and less of a moving target and also dedicated for end-users, it may be worth considering the use of www.debian.org. This will automatically add translations and is the native source for information addressing Debian. Yay!! I didn't think debian was so developer friendly to KDE stuff :-)) *smirk* Did I say anything wrong? :) 2. In order to provide new packages for the unstable distribution I'd like to see the experimental distribution of Debian used, since this enables using the entire infrastructure of Debian except for the buildds. Ok. Could you help providing the necessary steps get going so we can upload packages ? In the debian/changelog line use something like: kdegraphics (4:2.2.2-6.8) experimental; urgency=low and upload the package to ftp-master.debian.org or use an upload queue. Noël and Michael can probably help with this step. Regards, Joey -- Every use of Linux is a proper use of Linux. -- Jon Maddog Hall Please always Cc to me when replying to me on the lists.
