Re: [Pkg-xfce-devel] systemd/logind integration of desktop environments
Yves-Alexis Perez wrote: On ven., 2014-09-05 at 16:46 -0400, Joey Hess wrote: As part of the process described on this wiki page -- https://wiki.debian.org/DebianDesktop/Requalification/Jessie We're requesting some information from each desktop team, as well as the systemd maintainers: Hi, what kind of reply do you expect? Direct reply, group reply, or direct edit of the wiki page? Reply to task...@packages.debian.org (ccing your respective list) or edit the wiki page is ok. -- see shy jo signature.asc Description: Digital signature
systemd/logind integration of desktop environments
As part of the process described on this wiki page -- https://wiki.debian.org/DebianDesktop/Requalification/Jessie We're requesting some information from each desktop team, as well as the systemd maintainers: Is systemd (and logind etc) well integrated into the version of $desktop currently available in testing? Or are there eg, double-suspend issues? Links to open bug reports are useful here. -- see shy jo signature.asc Description: Digital signature
RFC: bringing back task packages
A long time ago, tasksel installed task packages, which were regular metapackages. This was dropped because the task packages had to Depend on many packages, which made the installed system brittle, and made testing propigation a problem. Now that Recommends are installed by default, I'm revisiting the idea of using task packages. It solves many issues and inconsistencies with tasksel vs the rest of Debian. The other problem with task packages before is that tasksel allowed the user to select from amoung all that were available, and this resulted in a confusing long mess of tasks to choose from. To avoid that, I intend to keep the ultimate decision about what tasks are displayed in tasksel under the control of the tasksel maintainers. But, I do hope that moving more of the maintenance of tasks to the developers responsible for those areas of Debian will result in a better selection of software and less work. We've already had some good progress in that area with the gnome metapackages which are used by tasksel. If tasksel was switched to task packages, the task packages would probably be initially built from tasksel's source. They could be split out of tasksel's source as other groups stepped up to maintain them. ## Questions for teams ### gnome Would the gnome team want to maintain a task-gnome? Much of tasksel's gnome task is already taken from the gnome-core and gnome metapackages, with a few more things added. task-gnome would not need to deal with core X desktop stuff; task-desktop would still handle that. Although we could move away from having a task-desktop if you'd prefer. There are also many localized desktop tasks. Mostly these add things like localization packages for openoffice, and occasionally some fonts. I'd like to see those be maintained in conjunction with task-gnome, but it would mean some coordination with the dozens of people who currently maintain those localization tasks. ### kde, lxde, xfce See above and s/gnome/$you/ ### cups Would the cups maintainers be interested in maintaining a task-print-server? Keeping the right ppds and cups packages in the task has been an ongoing issue for me. Note that a subset of cups is also installed as part of the desktop tasks, and it would also make sense to have a metapackage on the cups side that desktop tasks could use. The sole different currently is that openprinting-ppds is included in the print server task, but not the desktop tasks. ### blends I think there is interest in getting some blends displayed in Taskel? It's mostly orthagonal to this proposal, but this would help with giving you full control over what your tasks do. I do feel that blends need to be listed below the other tasks in tasksel, and probably with a divider between them. Also, we have been careful to only have ten tasks, to avoid overloading the user; and there is a limit to the length of the list before it begins scrolling, so the d-i team would have to look at the UI before adding Blends to the interface. ### i18n There are many language tasks in tasksel. It might be good to have the task packages be moved out of tasksel; I don't know if it'd make sense to have individual language teams maintain them, or what. If tasksel displayed Task packages' short Description fields, those would need to be translated. I know we have translated Descriptions but I don't know about coverage, or if that info is available when tasksel runs in d-i? ## Comparing tasksel and dpkg fields Key - Depends This would be an improvement, as new Depends of a task would be installed on upgrade; there is currently no way to upgrade a task and get new packages that have been added to it. Note that Britney already treats Key as Depends internally. So this change would not impact testing migration. Packages - Recommends Recommends may be better than what we have now in tasksel. If aptitude auto-selects *new* recommends of a previously installed package to be installed? Currently new Packages added to a task only affect new installations of that task. Most packages in a task need to be Recommends, to avoid wedging Britney, and to allow removing bits of a task that are not wanted. Note that the Task field on the package side, which is added to the archive based on data from tasksel, could go away. Enhances - ??? The Enhances fields are not truely the same as Depends (but are probably closer to Depends than to dpkg's Enhances). A task that Enhances other tasks is hidden, and auto-force-installed when the other tasks are installed. Relevance - ??? This is used to do some UI ordering of tasks. Closest equivilant is Priority, but it's not granular enough. Test- - ??? These fields specify programs to run to test if the task should be force-auto-installed, or hidden, or selected for installation. Description
Re: Bug#485655: debian-installer: The KDE images should use sudo too and configure KDE accordingly.
Frans Pop wrote: I've tested this and it appears to work, although the first time I somehow managed to crash the dcop server. I've tried both administrator mode in Control Center and the kuser user setup application. My proposal would be to: 1) add the kdesudo to the Key packages in kde-desktop task 2) add a hook script in pre-pkgsel.d that does: if db_get passwd/root-login [$RET = false ] \ db_get tasksel/desktop [ $RET = kde ]; then echo kdesudo kdesudo/kdesu boolean true | \ LANG=C chroot /target debconf-set-selections fi This means kdesudo already has the correct debconf setting before it gets installed by tasksel and the diversions get added automatically on installation. Alternatively we could do 2) + an apt-install in a finish-install.d hook script and then only if the desktop task was actually selected, but that would mean having to ensure that kdesudo gets included on images by debian-cd. Well, I don't really understand why kdesudo asks this question at all. Would there be some reason someone would install the package, and *not* have kdesudo used by default? The only reason I can think of for it to default to not being used is just what you're talking about doing -- including it in the task by default. :-) It seems easier at the moment to add your code, and include it in the task than it does to change the default or remove the debconf use, and come up with a way to detect which tasks were installed[1]. KDE team: any comments on this plan? Side note: I wonder how we ensure gksu is available on the first CD. It is only recommended by gnome-utils (pulled in by gnome-desktop-environment). It is not listed explicitly in either the gnome-desktop task or debian-cd. Joey: care to comment on this? It's pulled in by dependencies in gdm and update-notifier, at least. However, I've explicitly added it now. -- see shy jo [1] tasksel --list-tasks can do it, but hides hidden tasks like .. kde-desktop! signature.asc Description: Digital signature
Re: Processed: Let's reassign to unclutter
Raúl Sánchez Siles wrote: This could be a good explanation to low severity to the bug and/or possibly close it. I can do it for you if you want, in this case, please, let me know. I think the bug should be closed.. -- see shy jo signature.asc Description: Digital signature
Re: Processed: Let's reassign to unclutter
This is pretty much an unclutter faq. If you run unclutter with -grab, it well, grabs the mouse pointer. This can conflict with other programs, such as screen savers or window managers that also grab the mouse pointer. If that's a problem, then don't use the -grab option. Calling this a security hole is fairly absurd, IMHO. There are a variety of things that one can do to prevent a screensaver from running, including putting a kitten on your keyboard; this doesn't mean that kittens have security holes. -- see shy jo signature.asc Description: Digital signature
debian zeroconf group?
[Ccing maintainers of mdns stuff, please followup to debian-devel] With avahi in unstable we seem to have a fairly capable set of zeroconf/mdns tools in Debian now, albeit with some holes. There are for example some things like mod_dnssd that are not packaged yet and some interesting patches that aren't applied to some apps. And adding mdns to /etc/nsswitch.conf is still being worked out. I would like to investigate the possibility of adding a task to tasksel that fully sets up a system to prticipate in a zeroconf network. That would mean, you pick this task and you can resolve mdns names; if you installed a desktop, the desktop supports mdns; if you installed a web server or ssh server those services are published via mdns etc. There is still some integration work to do before that's possible, but it's my goal. I think a team to work on this stuff would be useful. Right now there seems to be no coordinated effort to put everything together and fill in the holes, just various people working on their own peices. While that scattershot approach has worked ok so far, getting everyone together integrating stuff could improve things a lot. If people agree let me know and I can do the standard alioth dance. -- see shy jo, who is primarily interested in zeroconf for his home network, and as a way to improve the ad-hoc networks that he seems to encounter more and more frequently at places like DebConf and family gatherings signature.asc Description: Digital signature
Bug#294832: FWD: insecure temporary file creation in kdelibs 3.3.2
Package: kdelibs-data Version: 4:3.3.2-1 Tags: security Severity: grave We're vulnerable. - Forwarded message from Davide Madrisan [EMAIL PROTECTED] - From: Davide Madrisan [EMAIL PROTECTED] Date: Fri, 11 Feb 2005 09:16:38 +0100 To: bugtraq@securityfocus.com Subject: insecure temporary file creation in kdelibs 3.3.2 Organization: QiNet s.r.l. User-Agent: KMail/1.7.2 The `dcopidlng' script in the KDE library package (kdelibs-3.3.2/dcop/dcopidlng/dcopidlng) creates temporary files in a unsecure manner. This bug has been fixed in 32 minutes (!) by Stephan Kulow, the KDE team leader. Here you can found the official patch: http://bugs.kde.org/show_bug.cgi?id=97608 Note: This bug has been find by `autospec', the work-in-progress tool used by the QiLinux team to (semi)automatically create specfiles from tarballs and update/check rpm packages. It's released under GPL and not QiLinux specific. The latest release can be found at the URL: ftp://ftp.qilinux.it/pub/QiLinux/devel/tools/autospec/ #include best/regards.h --- Davide Madrisan QiLinux Security Team Leader PGP keyID: 4B72B0B9 fp: 2B79 BFF1 EE33 EE8C 3258 E43C CDA8 EFF3 4B72 B0B9 PGP public key: http://pgp.mit.edu/ http://www.qilinux.it - End forwarded message - -- see shy jo signature.asc Description: Digital signature
Bug#294271: IDN support allows domain name spoofing
Package: konqueror Severity: normal Tags: security konqueror and other browsers which support IDN are vulnerable to domain spoofing via homograph characters in domain names. Please see http://lists.netsys.com/pipermail/full-disclosure/2005-February/031459.html for details, and note that this is CAN-2005-0237. Note: I have not marked this bug as releae critical, because it's not clear to me if spoofing attacks qualify. -- see shy jo signature.asc Description: Digital signature
Bug#285128: CAN-2004-1165: FTP command injection bug
Package: konqueror Version: 3.3.1 Tags: security Severity: serious CAN-2004-1165 is about a security hole in konqueror that allows arbitrary ftp commands to be inserted in a URL via URL-encoded newlines. Details about this hole are here: http://marc.theaimsgroup.com/?l=bugtraqm=110245752232681w=2 The advisory says that it affects version = 3.3.1, so perhaps our 3.2.3-1/2.3.3-1 in t-p-u/testing are not vulnerable. I've not checked. -- see shy jo signature.asc Description: Digital signature
Bug#285126: CAN-2004-1171: plain text password exposure
Adeodato Simó wrote: I've prepared kdelibs and kdebase uploads for this. I'm now looking for somebody to upload them for me. Are you one of the normal KDE maintainers? (Sorry, I'm not up-to-date on KDE maintenance.) If so, I can do the sponsoring. -- see shy jo signature.asc Description: Digital signature
Bug#261150: default-x-display-manager asked at inflated priority
Package: xdm,gdm,kdm Severity: normal xdm, gdm, and kde all ask the shared/default-x-display-manager at high priority. Debconf policy is that high priority is for items that don't have a reasonable default. I think that as long as any of xdm, gdm, or kdm is the default, that qualifies as a reaonable default display manager; each of them is usable. If there's some alternatives-style ranking going on to rank more usable display managers higher and make them more likely to be the default, that's even better. Anyway, right now an install of debian with gdm and kdm asks which to use, even at high priority, and I think that's an unnecessary question to ask for a high priority install. -- see shy jo -- see shy jo signature.asc Description: Digital signature
