Bug#1069609: Review of mount-zip
[This is not a formal review with the intent to sponsor, but prospective sponsors may use these findings as they see fit. Opinions are my own.] Summary: a missing run-time dependency on fuse needs to be fixed. [+] The orig.tar.gz is identical to the release file on Github. [-] Lintian reports a warnings: - d/rules sets DEB_HOST_ARCH which should not be necessary. Consider whether this is necessary; if so, add a lintian override or file a bug against lintian explaining the false positive. [+] License is GPL-3, licensecheck reports no odd copyrights or licenses [+] Package builds cleanly with sbuild -d unstable [+] d/control: The capitalisation of the synopsis and long description could be improved. The best practices[1] state that the synopsis gets no starting capital. (The full description should start with a Capital, but this is awkward as it starts with the name of the tool.) 1. https://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.en.html#bpp-debian-control Personal opinion: the last paragraph of the long description is a bit wishy-washy; it could be put more concisely by stating that the tool offers performance benefits on large archives with many files. [+] The rules file fits best practices [+] passes piuparts [-] tested installation on a clean system There seems to be a missing run-time dependency on fuse: dennis@sidvm:~$ wget https://github.com/google/mount-zip/archive/refs/tags/v1.0.14.zip --2024-05-18 00:30:21-- https://github.com/google/mount-zip/archive/refs/tags/v1.0.14.zip Resolving github.com (github.com)... 140.82.121.3 Connecting to github.com (github.com)|140.82.121.3|:443... connected. HTTP request sent, awaiting response... 302 Found Location: https://codeload.github.com/google/mount-zip/zip/refs/tags/v1.0.14 [following] --2024-05-18 00:30:22-- https://codeload.github.com/google/mount-zip/zip/refs/tags/v1.0.14 Resolving codeload.github.com (codeload.github.com)... 140.82.121.9 Connecting to codeload.github.com (codeload.github.com)|140.82.121.9|:443... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [application/zip] Saving to: ‘v1.0.14.zip’ v1.0.14.zip [ <=> ] 742.41K 3.31MB/sin 0.2s 2024-05-18 00:30:22 (3.31 MB/s) - ‘v1.0.14.zip’ saved [760225] dennis@sidvm:~$ mount-zip v1.0.14.zip mount-zip: Created mount point 'v1.0.14' fuse: failed to exec fusermount: No such file or directory After installing the fuse package, the program works as expected. OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#873922: [PATCH] Test for NULL file pointer for /sys/class/net//carrier
I can confirm that netcfg crashes in this situation, tested with version 1.189 (UNRELEASED) (git a218ebabc8cafdf5127e7ae006d3be15feef8824) I used the following method for testing and debugging this. You will need: - a clean build environment like a container or VM (I used Incus) - a basic VM to test on (qemu/libvirt) Set up Incus (following https://wiki.debian.org/Incus) incus create images:debian/12 debcon (Some additional steps to include home dir bind mount etc. skipped here.) Inside container: Update /etc/apt/sources.list to include unstable deb and deb-src. Set up the debian installer sources following https://wiki.debian.org/DebianInstaller/Build In debian-installer/packages/netcfg: (edit source files to include more debugging) dpkg-buildpackage -b --no-sign In debian-installer/installer/build: copy the udeb file to localudebs/ cp ../../packages/netcfg_1.189+test1_amd64.udeb localudebs/netcfg.udeb fakeroot make build_netboot Now copy the kernel and initrd to a location outside the container (easiest if a bind mount was used, otherwise incus file pull can be used). cd /var/tmp cp debian-installer/installer/build/dest/netboot/debian-installer/amd64/initrd.gz . cp debian-installer/installer/build/dest/netboot/debian-installer/amd64/linux . Use virt-manager to create a new VM: - type QEMU/KVM - Manual Installation - debiantesting - default mem/cpu - check the box for 'edit configuration before launch' In the hardware settings, add a second network interface In the boot settings, select the kernel and initrd in /var/tmp set the kernel boot parameters to "interface=invalid BOOT_DEBUG=2 auto=true" Start the installation procedure. For me this crashed netcfg. After adding more debugging to the code I found that ethtool-lite.c was opening /sys/class/net/invalid/carrier but that file does not exist so the file pointer returned is NULL. The code then proceed to fgets from the NULL pointer. Below is a small patch that remedies that situation. AS the installer would get stuck retrying the same interface name, the patch adds code to reset netcfg/choose_interface in case UNKNOWN is returned by ethtool_lite. --- ethtool-lite.c | 4 netcfg-common.c | 11 ++- 2 files changed, 14 insertions(+), 1 deletion(-) diff --git a/ethtool-lite.c b/ethtool-lite.c index a5f74c56..d30f8451 100644 --- a/ethtool-lite.c +++ b/ethtool-lite.c @@ -46,6 +46,10 @@ int ethtool_lite (const char * iface) char* filename = malloc(len); snprintf(filename, len, SYSCLASSNET "%s/carrier", iface); FILE* fp = fopen(filename, "r"); +if (!fp) { +di_warning("Could not open %s: %s", filename, strerror(errno)); +return UNKNOWN; +} free(filename); char result[2]; diff --git a/netcfg-common.c b/netcfg-common.c index f6006be3..a8889b5d 100644 --- a/netcfg-common.c +++ b/netcfg-common.c @@ -1486,6 +1486,7 @@ int netcfg_detect_link(struct debconfclient *client, const struct netcfg_interfa int gw_tries = NETCFG_GATEWAY_REACHABILITY_TRIES; const char *if_name = interface->name; const char *gateway = interface->gateway; +int connected; /* as returned by ethtool_lite */ if (!empty_str(gateway)) sprintf(arping, "arping -c 1 -w 1 -f -I %s %s", if_name, gateway); @@ -1538,7 +1539,8 @@ int netcfg_detect_link(struct debconfclient *client, const struct netcfg_interfa di_info("Detecting link on %s was cancelled", if_name); break; } -if (ethtool_lite(if_name) == 1) /* ethtool-lite's CONNECTED */ { +connected = ethtool_lite(if_name); +if (connected == 1) /* ethtool-lite's CONNECTED */ { di_info("Found link on %s", if_name); if (!empty_str(gateway) && !is_wireless_iface(if_name) && !is_layer3_qeth(if_name)) { @@ -1551,6 +1553,13 @@ int netcfg_detect_link(struct debconfclient *client, const struct netcfg_interfa rv = 1; break; +} else if (connected == 3) /* ethtool-lite UNKNOWN */ { +/* There can be multiple reasons for this situation but + the safest course is perhaps to forget + netcfg/choose_interface and drop out */ +di_info("Unknown interface name %s", if_name); +debconf_reset(client, "netcfg/choose_interface"); +break; } } -- 2.39.2
Bug#1051024: bookworm-pu: package igtf-policy-bundle/1.22-1~deb12u1
On 08-04-2024 19:30, Adam D. Barratt wrote: On Mon, 2024-04-08 at 14:26 +0200, Dennis van Dok wrote: I've uploaded a new version since unstable is already at 1.128-1. The package you've uploaded is versioned 1.128-1+deb12u1, which is higher than the version in unstable. The stable upload needs to have a lower version number, conventionally 1.128-1~deb12u1. It appears you've also uploaded a 1.128-1~deb12u1 package, which confusingly seems to be a rebuild of 1.12_7_-1 from unstable. I'm going to flag both uploads for rejection. Once you get confirmation of that having been actioned, if what you're actually aiming for is to get a rebuild of 1.128-1 into stable then please: - use 1.128-1~deb12u1 as the package version - attach a revised debdiff to this bug Hi Adam, sorry for the confusion, it's entirely my fault for not knowing how this works. The 1.128-1~deb12u1 should be the correct version, the uploaded version *is* a rebuild of 1.128-1 in unstable but I think I messed up the changelog. It's ok to reject them, I'll fix the changelog and upload a better version. Thanks, Dennis
Bug#1051024: bookworm-pu: package igtf-policy-bundle/1.22-1~deb12u1
I've uploaded a new version since unstable is already at 1.128-1.
Bug#1051024: bookworm-pu: package igtf-policy-bundle/1.22-1~deb12u1
On 23-09-2023 22:36, Adam D. Barratt wrote: [ Checklist ] [*] *all* changes are documented in the d/changelog [*] I reviewed all changes and I approve them [*] attach debdiff against the package in (old)stable You appear to have forgotten the debdiff. It could not be attached on the initial submission for some reason, so I attached it in message #12: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051024#12 [ ] the issue is verified as fixed in unstable Is this fixed in unstable or not? Yes, 1.122 is accepted into unstable in the mean time.
Bug#1051099: Acknowledgement (bookworm-pu: package igtf-policy-bundle/1.22-1~deb12u1)
Due to spam filtering this report came through later, it is in fact the same as #1051024 and should probably be merged or closed.
Bug#1051024: bookworm-pu: package igtf-policy-bundle/1.22-1~deb12u1
Package: release.debian.org Severity: normal Tags: bookworm User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: igtf-policy-bun...@packages.debian.org Control: affects -1 + src:igtf-policy-bundle [ Reason ] The IGTF bundle provides important trust anchors for the Research and Education communities. Both for reliance on the identity of servers for compute and storage services, as well as user identification based on personal certificates. A recent change in the rules for S/MIME certificates[1] has urged a change in the profiles for end user and robot certificates, effectively by 28 August 2023. Relying parties who need to authenticate users should install this update as soon as possible. 1. https://cabforum.org/smime-br/ More details about the change can be found on the web page of the upstream maintainer[2]. 2. https://www.nikhef.nl/~davidg/tcsg4/GEANT-TCSG4-private-CA-extension-20230712.pdf [ Impact ] Normally I would not propose to update the package in Debian stable but this change may break authentication for some users. They could install the package from unstable or backports (if available). [ Tests ] I normally install the packages on my own systems to try out that they work. Since the deployment is relatively straightforward there is rarely an issue. [ Risks ] There are no code changes between versions, it should be safe (in fact, recommended) to always install the latest version of the bundle. [ Checklist ] [*] *all* changes are documented in the d/changelog [*] I reviewed all changes and I approve them [*] attach debdiff against the package in (old)stable [ ] the issue is verified as fixed in unstable [ Changes ] See the upstream CHANGES file (or d/changelog).
Bug#1032431: installation-reports: Bullseye installation on Fujitsu LIFEBOOK U9312
On 21-03-2023 17:39, Cyril Brulebois wrote: Cyril Brulebois (2023-03-08): I should be able to share a small(-ish) ISO for you to test, so that you can check whether touchpad support becomes available. Same story as before: that'd be just about booting the installer, reaching the language selection screen, and letting us know whether the touchpad's working. Test ISO (without any firmware, just a fresh minimal installer build) available here for you to check whether that helps the touchpad become alive: https://people.debian.org/~kibi/bug-1032136/ Tested and the touchpad is now functional. The pointer moves as expected. Tapping on the pad does not translate to mouse clicks, but the touchpad buttons work correctly. Tap-to-click is a feature of the driver that I find annoying and normally leave off, but I'm not sure that should be the default for the installer. I have no real opinion on that, I just thought it was worth mentioning that it behaves that way.
Bug#1032431: installation-reports: Bullseye installation on Fujitsu LIFEBOOK U9312
On 08-03-2023 10:48, Cyril Brulebois wrote: Dennis van Dok (2023-03-08): I just tested it and what do you know: the module is loaded automatically. So the tweak to /etc/modules is no longer required. I am running a fairly new kernel: Linux bobo 6.1.0-5-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.12-1 (2023-02-15) x86_64 GNU/Linux The output of `lsmod` in your installed system would be nice, to check my lpss hypothesis (and possibly get new ideas if it doesn't check out). Here goes: Module Size Used by tun61440 2 uinput 20480 1 vboxnetadp 28672 0 vboxnetflt 32768 0 vboxdrv 602112 2 vboxnetadp,vboxnetflt ctr16384 3 ccm20480 9 rfcomm 94208 7 cmac 16384 3 algif_hash 16384 1 algif_skcipher 16384 1 af_alg 36864 6 algif_hash,algif_skcipher snd_seq_dummy 16384 0 snd_hrtimer16384 1 snd_seq90112 7 snd_seq_dummy snd_seq_device 16384 1 snd_seq qrtr 49152 4 ipmi_devintf 20480 0 ipmi_msghandler77824 1 ipmi_devintf bnep 28672 2 binfmt_misc24576 1 nls_ascii 16384 1 nls_cp437 20480 1 vfat 24576 1 fat90112 1 vfat snd_ctl_led24576 0 snd_soc_skl_hda_dsp24576 4 snd_soc_intel_hda_dsp_common20480 1 snd_soc_skl_hda_dsp snd_soc_hdac_hdmi 45056 1 snd_soc_skl_hda_dsp snd_sof_probes 24576 0 snd_hda_codec_hdmi 81920 1 snd_hda_codec_realtek 172032 1 snd_hda_codec_generic98304 1 snd_hda_codec_realtek ledtrig_audio 16384 2 snd_ctl_led,snd_hda_codec_generic snd_soc_dmic 16384 1 snd_sof_pci_intel_tgl16384 0 snd_sof_intel_hda_common 188416 1 snd_sof_pci_intel_tgl soundwire_intel49152 1 snd_sof_intel_hda_common iwlmvm385024 0 soundwire_generic_allocation16384 1 soundwire_intel soundwire_cadence 40960 1 soundwire_intel snd_sof_intel_hda 20480 1 snd_sof_intel_hda_common snd_sof_pci24576 2 snd_sof_intel_hda_common,snd_sof_pci_intel_tgl snd_sof_xtensa_dsp 16384 1 snd_sof_intel_hda_common snd_sof 274432 3 snd_sof_pci,snd_sof_intel_hda_common,snd_sof_probes mac80211 1175552 1 iwlmvm snd_sof_utils 20480 1 snd_sof snd_soc_hdac_hda 24576 1 snd_sof_intel_hda_common snd_hda_ext_core 40960 3 snd_sof_intel_hda_common,snd_soc_hdac_hdmi,snd_soc_hdac_hda snd_soc_acpi_intel_match73728 2 snd_sof_intel_hda_common,snd_sof_pci_intel_tgl x86_pkg_temp_thermal20480 0 snd_soc_acpi 16384 2 snd_soc_acpi_intel_match,snd_sof_intel_hda_common intel_powerclamp 20480 0 snd_soc_core 348160 8 soundwire_intel,snd_sof,snd_sof_intel_hda_common,snd_soc_hdac_hdmi,snd_soc_hdac_hda,snd_sof_probes,snd_soc_dmic,snd_soc_skl_hda_dsp btusb 65536 0 btrtl 28672 1 btusb coretemp 20480 0 btbcm 24576 1 btusb btintel45056 1 btusb snd_compress 28672 2 snd_soc_core,snd_sof_probes btmtk 16384 1 btusb kvm_intel 380928 0 bluetooth 950272 44 btrtl,btmtk,btintel,btbcm,bnep,btusb,rfcomm soundwire_bus 102400 3 soundwire_intel,soundwire_generic_allocation,soundwire_cadence libarc416384 1 mac80211 kvm 1138688 1 kvm_intel snd_hda_intel 57344 0 snd_intel_dspcfg 36864 3 snd_hda_intel,snd_sof,snd_sof_intel_hda_common snd_intel_sdw_acpi 20480 2 snd_sof_intel_hda_common,snd_intel_dspcfg irqbypass 16384 1 kvm iwlwifi 360448 1 iwlmvm snd_hda_codec 184320 8 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec_realtek,snd_soc_intel_hda_dsp_common,snd_soc_hdac_hda,snd_sof_intel_hda,snd_soc_skl_hda_dsp snd_hda_core 122880 11 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_ext_core,snd_hda_codec,snd_hda_codec_realtek,snd_soc_intel_hda_dsp_common,snd_sof_intel_hda_common,snd_soc_hdac_hdmi,snd_soc_hdac_hda,snd_sof_intel_hda jitterentropy_rng 16384 1 uvcvideo 131072 0 rapl 20480 0 processor_thermal_device_pci16384 0 processor_thermal_device20480 1 processor_thermal_device_pci snd_hwdep 16384 1 snd_hda_codec videobuf2_vmalloc 20480 1 uvcvideo iTCO_wdt 16384 0 processor_thermal_rfim16384 1 processor_thermal_device pmt_telemetry 16384 0 videobuf2_memops 20480 1 videobuf2_vmalloc intel_pmc_bxt 16384 1 iTCO_wdt videobuf2_v4l2 36864 1 uvcvideo processor_thermal_mbox16384 2 processor_thermal_rfim,processor_thermal_device mei_hdcp 24576 0 snd_pcm 159744
Bug#1032431: installation-reports: Bullseye installation on Fujitsu LIFEBOOK U9312
On 08-03-2023 07:03, Cyril Brulebois wrote: Hi Dennis, Dennis van Dok (2023-03-07): Can confirm that works; the alpha2 installer https://cdimage.debian.org/cdimage/bookworm_di_alpha2/amd64/iso-cd/debian-bookworm-DI-alpha2-amd64-netinst.iso Did see the wireless card and was able to get on my home wireless network. Thanks for confirming! It's currently sitting in /etc/modules, I could remove it to see if it is still needed. I think it is, I'm running the latest kernel: Testing a boot without it in /etc/modules would be awesome, yes. I just tested it and what do you know: the module is loaded automatically. So the tweak to /etc/modules is no longer required. I am running a fairly new kernel: Linux bobo 6.1.0-5-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.12-1 (2023-02-15) x86_64 GNU/Linux HTH, Dennis
Bug#1032431: installation-reports: Bullseye installation on Fujitsu LIFEBOOK U9312
Package: installation-reports Severity: normal Boot method: USB Image version: https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/11.6.0+nonfree/amd64/iso-cd/firmware-11.6.0-amd64-netinst.iso Date: 2023-03-02 Machine: Fujitsu LIFEBOOK U9312 Partitions: FilesystemType 1K-blocks Used Available Use% Mounted on udev devtmpfs 16196776 0 16196776 0% /dev tmpfs tmpfs 3247404 23843245020 1% /run /dev/mapper/bobo--vg-root ext4 1920358680 374068376 1448667676 21% / tmpfs tmpfs 16237012183456 16053556 2% /dev/shm tmpfs tmpfs 5120 8 5112 1% /run/lock /dev/nvme0n1p2ext2 481642171481 285176 38% /boot /dev/nvme0n1p1vfat 523248 5928 517320 2% /boot/efi tmpfs tmpfs 3247400 1283247272 1% /run/user/1000 Model: SAMSUNG MZVL22T0HBLB-00B07 (nvme) Disk /dev/nvme0n1: 2048GB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: Number Start End SizeFile system Name Flags 1 1049kB 538MB 537MB fat32 boot, esp 2 538MB 1050MB 512MB ext2 3 1050MB 2048GB 2047GB Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O*] Configure network: [O] Detect media: [O] Load installer modules: [O] Clock/timezone setup: [O] User/password setup:[O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Install tasks: [O] Install boot loader:[O] Overall install:[O] Comments/Problems: Using a netboot install image with non-free firmware; the wireless card was not detected during the installation so I used the wired network adapter instead. The touchpad was not working, but an external mouse could be used. This later turned out to be a minor issue but a cost me the most time. Loading the i2c_hid_acpi module got it going. Since this was a fairly new laptop I expected some things not to work (yet). The missing firmware files reported by the kernel could be downloaded from https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git which was sufficient to get the wireless card and bluetooth to work. I always expected to run the system in a mixed stable/testing setup because I wanted to install pipewire/wireplumber which seems to work better with Debian 12. I ended up switching almost entirely to testing. The sound card required the latest firmware from the SOF project. To get the digital microphone working a different topology file was needed as outlined on this page: https://thesofproject.github.io/latest/getting_started/intel_debug/suggestions.html#digital-mic-issues And this bug report: https://github.com/thesofproject/linux/issues/4099 The system seems to do great otherwise, as it is my daily workhorse to replace an earlier Fujitsu model (LIFEBOOK U937). The only non-functioning element is the Fujitsu PalmSecure biometric sensor. Also see the hardware report https://linux-hardware.org/?probe=19a72f502b -- Package-specific info: == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION="Debian GNU/Linux installer" DISTRIB_RELEASE="11 (bullseye) - installer build 20210731+deb11u7+b1" X_INSTALLATION_MEDIUM=cdrom == Installer hardware-summary: == uname -a: Linux bobo 5.10.0-20-amd64 #1 SMP Debian 5.10.158-2 (2022-12-13) x86_64 GNU/Linux lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation Device [8086:4601] (rev 04) lspci -knn: Subsystem: Fujitsu Client Computing Limited Device [1e26:0087] lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation Device [8086:46a8] (rev 0c) lspci -knn: Subsystem: Fujitsu Client Computing Limited Device [1e26:009c] lspci -knn: 00:04.0 Signal processing controller [1180]: Intel Corporation Device [8086:461d] (rev 04) lspci -knn: Subsystem: Fujitsu Client Computing Limited Device [1e26:0087] lspci -knn: 00:06.0 PCI bridge [0604]: Intel Corporation Device [8086:464d] (rev 04) lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:07.0 PCI bridge [0604]: Intel Corporation Device [8086:466e] (rev 04) lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:07.1 PCI bridge [0604]: Intel Corporation Device [8086:463f] (rev 04) lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:08.0 System peripheral [0880]: Intel Corporation Device [8086:464f] (rev 04) lspci -knn: Subsystem: Fujitsu Client Computing Limited Device [1e26:0087] lspci -knn: 00:0a.0 Signal processing controller [1180]: Intel
Bug#1032430: python3-debianbts: Dependency on python3-pysimplesoap >= 1.16.2-5
Package: python3-debianbts Version: 4.0.1 Severity: minor Dear Maintainer, I tried running reportbug in a mixed bullseye/bookworm system. This led to the following backtrace: Traceback (most recent call last): File "/usr/bin/reportbug", line 40, in from reportbug import utils File "/usr/lib/python3/dist-packages/reportbug/utils.py", line 70, in from . import debbugs # noqa: E402 ^ File "/usr/lib/python3/dist-packages/reportbug/debbugs.py", line 33, in import debianbts File "/usr/lib/python3/dist-packages/debianbts/__init__.py", line 1, in from debianbts.debianbts import * # noqa ^ File "/usr/lib/python3/dist-packages/debianbts/debianbts.py", line 21, in import pysimplesoap File "/usr/lib/python3/dist-packages/pysimplesoap/__init__.py", line 16, in from . import client, server, simplexml, transport File "/usr/lib/python3/dist-packages/pysimplesoap/client.py", line 33, in from .transport import get_http_wrapper, set_http_wrapper, get_Http File "/usr/lib/python3/dist-packages/pysimplesoap/transport.py", line 109, in if 'timeout' in inspect.getargspec(httplib2.Http.__init__)[0]: ^^ AttributeError: module 'inspect' has no attribute 'getargspec'. Did you mean: 'getargs'? This was while using python3-debianbts version 3.1.0, so it may not be repeatable with 4.0.1. Upgrading the python3-pysimplesoap version from 1.16.2-3 to 1.16.2-5 resolved the issue. It would seem that there is a change in python3-pysimplesoap that is somehow exposed by python3-debianbts, which should probably be reflected in the dependencies (even if it will never occur in a pure bookworm setup). -- System Information: Debian Release: bookworm/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable'), (100, 'testing'), (50, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-5-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-debianbts depends on: ii python3 3.11.2-1 ii python3-pysimplesoap 1.16.2-5 python3-debianbts recommends no packages. python3-debianbts suggests no packages. -- no debconf information
Bug#1006410: igtf-policy-classic: when cancelling the debconf dialog, all certs are removed
Confirmed; in fact, the symbolic links are already removed while the debconf dialog is running, which is equally undesirable. I'll review the configuration script to find a fix.
Bug#997021: RFS: igtf-policy-bundle/1.113-1~bpo11+1 -- IGTF experimental Certificate Authorities
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "igtf-policy-bundle". The package is already in stable and buster-backerports. It is NEW for bullseye backports and I would like to maintain updating it there. The package has regular (~monthly) updates of the trust anchors which is why it makes sense to also keep backporting it. * Package name: igtf-policy-bundle Version : 1.113-1~bpo11+1 Upstream Author : IGTF * URL : http://www.igtf.net/ * License : CC-BY-3.0, MPL-1.1 * Vcs : https://github.com/dvandok/igtf-policy-bundle Section : misc It builds those binary packages: igtf-policy-classic - IGTF classic profile for Certificate Authorities igtf-policy-mics - IGTF MICS profile for Certificate Authorities igtf-policy-slcs - IGTF SLCS profile for Certificate Authorities igtf-policy-iota - IGTF IOTA profile for Certificate Authorities igtf-policy-unaccredited - IGTF unaccredited Certificate Authorities igtf-policy-experimental - IGTF experimental Certificate Authorities To access further information about this package, please visit the following URL: https://mentors.debian.net/package/igtf-policy-bundle/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/i/igtf-policy-bundle/igtf-policy-bundle_1.113-1~bpo11+1.dsc Changes since the last upload: igtf-policy-bundle (1.113-1~bpo11+1) bullseye-backports; urgency=medium . * Rebuild for bullseye-backports. . igtf-policy-bundle (1.113-1) unstable; urgency=medium . * New upstream release: * [Changes from 1.112 to 1.113 (4 October 2021)] * Suspended MD-GRID CA due to network resolution issues (MD) * [Changes from 1.111 to 1.112 (16 August 2021)] * Updated ANSPGrid CA with extended validity date (BR) * [Changes from 1.110 to 1.111 (24 May 2021)] * Removed discontinued NERSC-SLCS CA (US) * Removed discontinued MYIFAM CA (MY) * [Changes from 1.109 to 1.110 (22 March 2021)] * Removed INFN-CA-2015 that has disappeared operationally (IT) Regards, -- Dennis van Dok
Bug#939926: This is only on Wayland
The bug should probably be tagged for Wayland; since I switched back to Gnome on X11 the problem is gone. (As well as some other problems. This Wayland thing is not ready for prime time.)
Bug#939926: gnome-shell: Window screen and workspace locations forgotten when working with an external monitor
Package: gnome-shell Version: 3.30.2-9 Severity: normal Dear Maintainer, the window placement on my external screen is not remembered when I unplug and suspend my laptop. I upgraded from Debian stretch to buster. I'm using a laptop with a plain Gnome desktop. At home, I use just the laptop, but at work I plug in an external screen which I set as the primary display (i.e. it gets the menu bar and workspaces). I leave most of my windows open when I go home; I simply detach the screen and suspend the laptop. When I come in the next day and re-attach the external screen, it is correctly positioned and set as the primary display again, but none of the application windows are placed back in their original position. They are all piled on top of one another on the laptop screen (now secondary screen). I typically keep each application on its own workspace. Before the upgrade this used to work smartly; applications that were running the day before would end up on their own workspace. After the upgrade, the window position is remembered only when the laptop has not been suspended in the mean time. A simple test to replicate: 1. set up laptop with Debian buster and Gnome 3 desktop 2. attach external screen 3. configure external display to be the primary 4. launch an application. Place on primary display. 5. Detach screen. 6. Reattach screen. 7. Observe position of application window. If between steps 5 and 6 a suspend an wake up the laptop, the observed position of the application reverts to the laptop rather than the external screen. -- System Information: Debian Release: 10.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-rt-amd64 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8), LANGUAGE=nl_NL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnome-shell depends on: ii dconf-gsettings-backend [gsettings-backend] 0.30.1-2 ii evolution-data-server3.30.5-1 ii gir1.2-accountsservice-1.0 0.6.45-2 ii gir1.2-atspi-2.0 2.30.0-7 ii gir1.2-freedesktop 1.58.3-2 ii gir1.2-gcr-3 3.28.1-1 ii gir1.2-gdesktopenums-3.0 3.28.1-1 ii gir1.2-gdm-1.0 3.30.2-3 ii gir1.2-geoclue-2.0 2.5.2-1 ii gir1.2-glib-2.0 1.58.3-2 ii gir1.2-gnomebluetooth-1.03.28.2-3 ii gir1.2-gnomedesktop-3.0 3.30.2.1-2 ii gir1.2-gtk-3.0 3.24.5-1 ii gir1.2-gweather-3.0 3.28.2-2 ii gir1.2-ibus-1.0 1.5.19-4 ii gir1.2-mutter-3 3.30.2-7 ii gir1.2-nm-1.01.14.6-2 ii gir1.2-nma-1.0 1.8.20-1.1 ii gir1.2-pango-1.0 1.42.4-7~deb10u1 ii gir1.2-polkit-1.00.105-25 ii gir1.2-rsvg-2.0 2.44.10-2.1 ii gir1.2-soup-2.4 2.64.2-2 ii gir1.2-upowerglib-1.00.99.10-1 ii gjs 1.54.3-1 ii gnome-backgrounds3.30.0-1 ii gnome-settings-daemon3.30.2-3 ii gnome-shell-common 3.30.2-9 ii gsettings-desktop-schemas3.28.1-1 ii libatk-bridge2.0-0 2.30.0-5 ii libatk1.0-0 2.30.0-2 ii libc62.28-10 ii libcairo21.16.0-4 ii libcanberra-gtk3-0 0.30-7 ii libcanberra0 0.30-7 ii libcroco30.6.12-3 ii libecal-1.2-19 3.30.5-1 ii libedataserver-1.2-233.30.5-1 ii libgcr-base-3-1 3.28.1-1 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libgirepository-1.0-11.58.3-2 ii libgjs0g 1.54.3-1 ii libglib2.0-0 2.58.3-2 ii libglib2.0-bin 2.58.3-2 ii libgstreamer1.0-01.14.4-1 ii libgtk-3-0 3.24.5-1 ii libical3 3.0.4-3 ii libjson-glib-1.0-0 1.4.4-2 ii libmutter-3-03.30.2-7 ii libnm0 1.14.6-2 ii libpango-1.0-0 1.42.4-7~deb10u1 ii libpangocairo-1.0-0
Bug#880419: igtf-policy-{unaccredited,experimental}: leaves certificate links in /etc/ssl/certs after purge
On 28-11-17 17:55, Andreas Beckmann wrote: > Sounds like you want to activate the 'update-ca-certificates' trigger > from ca-certificates after changes (including removal or end of > ca-certificates integration) to your certificates s.t. the links get > updated (or removed) in a deterministic manner. True, but that will be no longer necessary once the certificates are no longer installed under /usr/share/ca-certificates.
Bug#880419: igtf-policy-{unaccredited,experimental}: leaves certificate links in /etc/ssl/certs after purge
Thanks for the report. The bug is an unfortunate side effect of the integration with ca-certificates. The installation of the certificate files under /usr/share/ca-certificates has the consequence that they are automatically linked to /etc/ssl/certs whenever the ca-certificates package is (re)configured. In retrospect I should never have implemented the integration of the IGTF certificates with the system's ca-certificates; their purpose is so different that it does not make sense to trust them in general for e-mail signatures or web security. I am going to change the installation paths so none of this will happen anymore, but the piuparts test as run will still fail the upgrade; the bug is in the older version. Anyway, the symlinks are created by the ca-certificates package. Removing or reconfiguring ca-certificates gets rid of the symlinks.
Bug#875406: igtf-policy-*: unowned directory after purge: /etc/grid-security/
Thanks for looking into this. In earlier versions, the directory was owned by this package. The change is due to the way bug [#920259] is solved. [#820259] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820259 The idea is that the package creates files (symlinks, actually, but that is beside the point) in a directory that can be configured by the administrator through debconf. This configuration can be done at any time, before or after the package is installed. The default is /etc/grid-security/certificates, a long established convention for grid middleware; typically other files are found in /etc/grid-security as well. The package installation scripts try to be clever about cleaning up. They will remove the last directory if it is empty after deinstallation, but it would be presumptuous to clean out the entire directory hierarchy above; the location set in debconf could be some deep path under control of the sysadmin. There is actually a solution of this, which requires the installation scripts to record when directories are created, and to remove them afterward if they were created and are currently empty.
Bug#870136:
On 30-07-17 12:27, Dio Putra wrote: > Hi, sorry for this accident. However, please correct this typo in here. > Thanks. OK, fixed; thanks for the translation. Dennis
Bug#869689: Bug#870080: igtf-policy-bundle: [INTL:pt] Updated Portuguese translation for debconf messages
Thanks, but now I have two translations. The earlier translation is tracked in bug #869689. Below is the diff; could you help sort out what to do about it? Cheers, Dennis @@ -1,22 +1,22 @@ -# Translation of igtf-policy-bundle's debconf messages to European Portuguese +# Translation of igtf-policy-bundle's debconf messages to Portuguese # Copyright (C) 2014 THE igtf-policy-bundle'S COPYRIGHT HOLDER # This file is distributed under the same license as the igtf-policy-bundle package. # -# Américo Monteiro, 2014, 2017. +# Américo Monteiro , 2014. +# Rui Branco - DebianPT , 2017. msgid "" msgstr "" "Project-Id-Version: igtf-policy-bundle 1.85-1\n" "Report-Msgid-Bugs-To: igtf-policy-bun...@packages.debian.org\n" "POT-Creation-Date: 2017-07-24 17:44+0200\n" -"PO-Revision-Date: 2017-07-25 17:59+\n" -"Last-Translator: Américo Monteiro \n" -"Language-Team: Portuguese <>\n" +"PO-Revision-Date: 2017-07-29 17:05+0200\n" +"Last-Translator: Rui Branco - DebianPT \n" +"Language-Team: Portuguese \n" "Language: pt\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=2; plural=(n != 1);\n" -"X-Generator: Lokalize 2.0\n" #. Type: boolean #. Description @@ -94,14 +94,12 @@ msgid "" "The default location /etc/grid-security/certificates should work fine in " "most cases." msgstr "" -"A localização predefinida /etc/grid-security/certificates deverá funcionar " -"bem na maioria dos casos." +"O local por predefinição /etc/grid-security/certificates deverá funcionar " +"correctamente na maior parte dos casos." #. Type: string #. Description #: ../templates.in:5001 msgid "An alternative location can be given here if needed." -msgstr "" -"Pode ser fornecida aqui uma localização alternativa se tal for necessário." - +msgstr "Um local alternativo pode ser fornecido se necessário."
Bug#869962: [INTL:sv] Swedish strings for igtf-policy-bundle debconf
> Thanks for the translation, Martin. I saw a small typo in one string. > ("ages" should instead be "anges"). Fixed; normally contributors to the translation are mentioned in the changelog; would you like attribution for this change? Dennis
Bug#869962: [INTL:sv] Swedish strings for igtf-policy-bundle debconf
On 28-07-17 08:53, Martin Bagge wrote: > package: igtf-policy-bundle > severity: wishlist > tags: patch l10n > > Please consider to add this file to translation of debconf. Will do, thanks!
Bug#869811: igtf-policy-bundle: [INTL:ru] Russian debconf templates translation update
Thanks for the update! Cheers, Dennis
Bug#869795: network-manager-openvpn-gnome: can't specify route without gateway or use vpn_gateway
Package: network-manager-openvpn-gnome Version: 1.2.8-2 Severity: normal Dear Maintainer, I tried to configure openvpn through the Gnome dialogs. In the IPv4 tab adding a route cannot leave the gateway and metric fields empty, although they have reasonable defaults and are not required in OpenVPN per se. I tried to import a configuration file that mentions a route with the vpn_gateway setting and it showed an error message "unsupported 3th argument vpn_gateway to "route" " Manually editing the Network Manager file does work (leaving out everything but the network range) and the VPN connection works fine, but I cannot edit the connection through the dialog: it refuses to save until I fill out the gateway and metric field. The right thing to do for the dialog would be to accept empty fields and let openvpn use defaults. -- System Information: Debian Release: 9.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8), LANGUAGE=nl_NL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages network-manager-openvpn-gnome depends on: ii libatk1.0-0 2.22.0-1 ii libc62.24-11+deb9u1 ii libcairo-gobject21.14.8-1 ii libcairo21.14.8-1 ii libdbus-1-3 1.10.18-1 ii libdbus-glib-1-2 0.108-2 ii libgdk-pixbuf2.0-0 2.36.5-2 ii libglib2.0-0 2.50.3-2 ii libgtk-3-0 3.22.11-1 ii libnm-glib-vpn1 1.6.2-3 ii libnm-glib4 1.6.2-3 ii libnm-gtk0 1.4.4-1 ii libnm-util2 1.6.2-3 ii libnm0 1.6.2-3 ii libnma0 1.4.4-1 ii libpango-1.0-0 1.40.5-1 ii libpangocairo-1.0-0 1.40.5-1 ii libsecret-1-00.18.5-3.1 ii network-manager-openvpn 1.2.8-2 network-manager-openvpn-gnome recommends no packages. network-manager-openvpn-gnome suggests no packages. -- no debconf information
Bug#869689: igtf-policy-bundle: [INTL:pt] Updated Portuguese translation - debconf messages
On 25-07-17 19:01, Américo Monteiro wrote: > Package: igtf-policy-bundle > Version:1.85-1 > Tags: l10n, patch > Severity: wishlist > > Updated Portuguese translation for igtf-policy-bundle's debconf messages > Translator: Américo Monteiro> Feel free to use it. > > For translation updates please contact 'Last Translator' > One question: the mail address of the Portuguese translation team is left empty. Previously it was . Is this correct? Cheers, Dennis
Bug#869689: igtf-policy-bundle: [INTL:pt] Updated Portuguese translation - debconf messages
On 25-07-17 19:01, Américo Monteiro wrote: > Package: igtf-policy-bundle > Version:1.85-1 > Tags: l10n, patch > Severity: wishlist > > Updated Portuguese translation for igtf-policy-bundle's debconf messages > Translator: Américo Monteiro> Feel free to use it. > > For translation updates please contact 'Last Translator' > Thanks!
Bug#856122: update: calf plug-ins do work, calf-ladspa conflict
I've run some tests and debugging sessions; I noticed a few problematic behaviours with the Calf plugins but they seem have a common origin. I had both calf-plugins *and* calf-ladspa on my system, both containing calf.so with a subtly different implementation. The latter packages comes from lmms. I removed calf-ladspa and now it seems to be ok. I have not tried the Debian stretch package of ardour5 yet, I'm still running my newer 5.9.0 build.
Bug#856122: Tried 5.9.0, still the same
I was hoping a later release would not suffer from this. Here is what I did: (I'm running 'stretch' at the moment.) apt-get source ardour apt-get build-dep ardour Downloaded the latest ardour sources from https://community.ardour.org/src/ (5.9.0) using uscan. unpacked the sources, copied the debian/ files from the 5.5.0 source tree. I had to disable the 0080-more-spelling.patch because it wouldn't cleanly apply (needs an update). Otherwise dpkg-buildpackage -b --no-sign produced a new package. Installed and tested. Bug is still reproducible. My versions: ardour 1:5.9.0~dfsg-1 libcairo2:amd64 1.14.8-1 calf-plugins 0.0.60-4+b1 -- D.H. van Dok :: System administrator :: www.nikhef.nl/grid :: Phone +31 20 592 22 28 :: http://www.nikhef.nl/~dennisvd/
Bug#854443: nm-openvpn: dialog asks for private key password, but does not re-query when password turns out wrong
Package: network-manager-openvpn Version: 0.9.10.0-1 Severity: normal File: nm-openvpn Starting a connection through nm-applet; a dialog appears asking for the private key password (it never did before, somehow the password must have been forgotten by the keyring). I typed a passphrase, apparently the wrong one, and the connection failes. Any subsequent attempt to initiate the connection through the nm-applet fails immediately; no new dialog appears to ask the correct passphrase. -- System Information: Debian Release: 8.7 APT prefers stable APT policy: (990, 'stable'), (50, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-dvdrt-amd64 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=nl_NL.utf8, LC_CTYPE=nl_NL.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages network-manager-openvpn depends on: ii libc6 2.19-18+deb8u7 ii libdbus-1-3 1.8.22-0+deb8u1 ii libdbus-glib-1-2 0.102-1 ii libglib2.0-0 2.42.1-1+b1 ii libnm-glib-vpn1 0.9.10.0-7 ii libnm-glib4 0.9.10.0-7 ii libnm-util2 0.9.10.0-7 ii openvpn 2.3.4-5+deb8u1 network-manager-openvpn recommends no packages. network-manager-openvpn suggests no packages. -- no debconf information
Bug#854311: unblock: lcmaps-plugins-jobrep/1.5.3-4
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package lcmaps-plugins-jobrep Package no longer FTBFS with the introduction of OpenSSL 1.1. diff -Nru lcmaps-plugins-jobrep-1.5.3/debian/changelog lcmaps-plugins-jobrep-1.5.3/debian/changelog --- lcmaps-plugins-jobrep-1.5.3/debian/changelog2016-12-19 12:12:50.0 +0100 +++ lcmaps-plugins-jobrep-1.5.3/debian/changelog2017-01-27 12:33:38.0 +0100 @@ -1,3 +1,9 @@ +lcmaps-plugins-jobrep (1.5.3-4) unstable; urgency=medium + + * Update to build against OpenSSL 1.1 + + -- Dennis van Dok <denni...@nikhef.nl> Fri, 27 Jan 2017 12:33:38 +0100 + lcmaps-plugins-jobrep (1.5.3-3) unstable; urgency=medium * Update dependency of lcmaps-plugins-jobrep-admin to diff -Nru lcmaps-plugins-jobrep-1.5.3/debian/control lcmaps-plugins-jobrep-1.5.3/debian/control --- lcmaps-plugins-jobrep-1.5.3/debian/control 2016-12-19 12:11:24.0 +0100 +++ lcmaps-plugins-jobrep-1.5.3/debian/control 2017-01-27 12:33:38.0 +0100 @@ -5,7 +5,7 @@ Uploaders: Mischa Salle <msa...@nikhef.nl> Build-Depends: cdbs, debhelper (>= 7.0.50~), dh-autoreconf, autotools-dev, lcmaps-basic-interface, unixodbc-dev, libssl-dev, pkg-config -Standards-Version: 3.9.5 +Standards-Version: 3.9.8 Homepage: https://wiki.nikhef.nl/grid/LCMAPS Vcs-Svn: https://ndpfsvn.nikhef.nl/repos/mwsec/packaging/debian/trunk/lcmaps-plugins-jobrep Vcs-Browser: http://ndpfsvn.nikhef.nl/viewvc/mwsec/packaging/debian/trunk/lcmaps-plugins-jobrep diff -Nru lcmaps-plugins-jobrep-1.5.3/debian/patches/openssl1.1.patch lcmaps-plugins-jobrep-1.5.3/debian/patches/openssl1.1.patch --- lcmaps-plugins-jobrep-1.5.3/debian/patches/openssl1.1.patch 1970-01-01 01:00:00.0 +0100 +++ lcmaps-plugins-jobrep-1.5.3/debian/patches/openssl1.1.patch 2017-01-27 12:33:38.0 +0100 @@ -0,0 +1,111 @@ +From: Micha Sallé <msa...@nikhef.nl> +Subject: Fixes for compatibility with OpenSSL 1.1 + +--- a/src/jobrep/jobrep_data_handling.c b/src/jobrep/jobrep_data_handling.c +@@ -1134,7 +1134,7 @@ + char*subject_DN = NULL, *issuer_DN = NULL, *not_before_str = NULL, *not_after_str = NULL; + time_t not_before = 0, not_after = 0; + X509*cert = NULL; +-unsigned char *serialnr = NULL; ++char *serialnr = NULL; + + if ((db_handle == NULL) || (px509_chain == NULL)) { + return -1; +@@ -1231,27 +1231,25 @@ + return -1; + } + +-unsigned char * ++char * + jobrep_get_serialnumber_as_string(X509 *cert) { +-ASN1_INTEGER *cert_Serial = NULL; +-unsigned char *serialNumberDER = NULL, *temp = NULL, *serialStr = NULL; ++ASN1_INTEGER *serial = NULL; + char *subject_DN = NULL; +-size_t len; +-int j,serialLen; ++BIGNUM *bn_serial; ++char *serialStr = NULL; + + if (cert == NULL) + return NULL; + +-cert_Serial = X509_get_serialNumber(cert); +-if (cert_Serial == NULL) { ++if ( (serial = X509_get_serialNumber(cert)) == NULL) { + /* For debugging purposes extract the Subject DN */ + subject_DN = X509_NAME_oneline(X509_get_subject_name(cert),NULL,0); + if (subject_DN) { +-lcmaps_log(LOG_DEBUG, "%s: certificate passed with subject DN \"%s\" didn't contain a serial number.\n", ++lcmaps_log(LOG_WARNING, "%s: certificate passed with subject DN \"%s\" didn't contain a serial number.\n", +__func__, subject_DN); + free(subject_DN); + } else { +-lcmaps_log(LOG_DEBUG, "%s: certificate passed doesn't have a serialnumber and also lacks a subject DN. " \ ++lcmaps_log(LOG_WARNING, "%s: certificate passed doesn't have a serialnumber and also lacks a subject DN. " \ + "This is completely weird and doesn't even look like a certificate. " \ + "Are you a waiter because you seem to be feeding me soup?\n", + __func__); +@@ -1259,44 +1257,15 @@ + return NULL; + } + +-serialLen = i2c_ASN1_INTEGER(cert_Serial, NULL); +-if (serialLen <= 0) { +-lcmaps_log(LOG_INFO, "%s: Conversion of a certificate serial number from ASN1_INTEGER to DER failed\n", +- __func__); +-return NULL; +-} +- +-/* Note: serialLen is int and >0 */ +-temp = serialNumberDER = malloc((size_t)serialLen); +-if (serialNumberDER == NULL) { +-lcmaps_log(LOG_DEBUG, "%s: Could not allocate %d bytes\n", serialLen); +-return NULL; +-} +-/* Warning, the temp variable will be displaced, use the serialNumberDER instead. */ +-serialLen = i2c_ASN1_INTEGER(cert_Serial, ); +- +-/* Allocate as a Hex
Bug#854309: unblock: lcas-lcmaps-gt4-interface/0.3.0-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package lcas-lcmaps-gt4-interface The package no longer FTBFS with the fixing of #828374. diff -Nru lcas-lcmaps-gt4-interface-0.3.0/debian/changelog lcas-lcmaps-gt4-interface-0.3.0/debian/changelog --- lcas-lcmaps-gt4-interface-0.3.0/debian/changelog2014-01-20 16:02:08.0 +0100 +++ lcas-lcmaps-gt4-interface-0.3.0/debian/changelog2017-01-27 14:01:07.0 +0100 @@ -1,3 +1,9 @@ +lcas-lcmaps-gt4-interface (0.3.0-3) unstable; urgency=medium + + * Fix for OpenSSL 1.1 compatibility. (Closes: 828374) + + -- Dennis van Dok <denni...@nikhef.nl> Fri, 27 Jan 2017 14:01:07 +0100 + lcas-lcmaps-gt4-interface (0.3.0-2) unstable; urgency=low [ Logan Rosen ] diff -Nru lcas-lcmaps-gt4-interface-0.3.0/debian/control lcas-lcmaps-gt4-interface-0.3.0/debian/control --- lcas-lcmaps-gt4-interface-0.3.0/debian/control 2014-01-14 16:33:10.0 +0100 +++ lcas-lcmaps-gt4-interface-0.3.0/debian/control 2017-01-27 13:57:11.0 +0100 @@ -6,7 +6,7 @@ lcmaps-globus-interface, lcas-interface, libglobus-gridmap-callout-error-dev, pkg-config -Standards-Version: 3.9.5 +Standards-Version: 3.9.8 Section: libs Homepage: https://wiki.nikhef.nl/grid/Site_Access_Control Vcs-Svn: https://ndpfsvn.nikhef.nl/repos/mwsec/packaging/debian/trunk/lcas-lcmaps-gt4-interface diff -Nru lcas-lcmaps-gt4-interface-0.3.0/debian/patches/openssl1.1.patch lcas-lcmaps-gt4-interface-0.3.0/debian/patches/openssl1.1.patch --- lcas-lcmaps-gt4-interface-0.3.0/debian/patches/openssl1.1.patch 1970-01-01 01:00:00.0 +0100 +++ lcas-lcmaps-gt4-interface-0.3.0/debian/patches/openssl1.1.patch 2017-01-27 14:01:07.0 +0100 @@ -0,0 +1,25 @@ +From: Micha Sallé <msa...@nikhef.nl> +Subject: Fix for compatibility with OpenSSL 1.1 +Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828374 +--- a/src/llgt_globus_internal.h b/src/llgt_globus_internal.h +@@ -83,6 +83,19 @@ + OM_uint32 req_flags; + OM_uint32 ctx_flags; + int cred_obtained; ++#if OPENSSL_VERSION_NUMBER >= 0x1100L ++/** For GCM ciphers, sequence number of next read MAC token */ ++uint64_tmac_read_sequence; ++/** For GCM ciphers, sequence number of next write MAC token */ ++uint64_tmac_write_sequence; ++/** For GCM ciphers, key for MAC token generation/validation */ ++unsigned char * mac_key; ++/** ++ * For GCM ciphers, fixed part of the IV for MAC token ++ * generation/validation ++ */ ++unsigned char * mac_iv_fixed; ++#endif + SSL * gss_ssl; + BIO * gss_rbio; + BIO * gss_wbio; diff -Nru lcas-lcmaps-gt4-interface-0.3.0/debian/patches/series lcas-lcmaps-gt4-interface-0.3.0/debian/patches/series --- lcas-lcmaps-gt4-interface-0.3.0/debian/patches/series 2014-01-14 13:40:21.0 +0100 +++ lcas-lcmaps-gt4-interface-0.3.0/debian/patches/series 2017-01-27 13:54:02.0 +0100 @@ -1,2 +1,3 @@ setup-plugin-subdir.patch setup-no-flavor.patch +openssl1.1.patch unblock lcas-lcmaps-gt4-interface/0.3.0-3 -- System Information: Debian Release: 8.7 APT prefers stable APT policy: (990, 'stable'), (50, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-dvdrt-amd64 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=nl_NL.utf8, LC_CTYPE=nl_NL.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#828376: Bug#828375: OpenSSL: The LCMAPS/VOMS/Globus cluster
On 29-01-17 22:07, Mischa Salle wrote: > Hi Sebastian, > > that looks perfect. I just emailed Dennis (my direct colleague) asking > him to apply the exact same patch! Hi Sebastian, You are free to go ahead with the NMU; alternatively I could upload the fix through Mentors but it amounts to the same thing. Sorry we missed this one. Cheers, Dennis > > Best wishes, > Mischa Sallé > > On Sun, Jan 29, 2017 at 09:57:59PM +0100, Sebastian Andrzej Siewior wrote: >> On 2017-01-28 15:38:40 [+0200], Adrian Bunk wrote: >>> Hi, >> Hi, >> >>> #828375 lcmaps-plugins-verify-proxy: FTBFS with openssl 1.1.0 >>> #828376 lcmaps-plugins-voms: FTBFS with openssl 1.1.0 >>> >>> When trying to fix these FTBFS with OpenSSL 1.1 by switching LCMAPS to >>> 1.0.2 I end up also moving VOMS and Globus to OpenSSL 1.0.2 >>> >>> Is this the way to forward, or is there a better solution available >>> for lcmaps-plugins-verify-proxy and lcmaps-plugins-voms in stretch? >> >> If I read this right, #828375 is waiting for the usual sponsor and I see >> nothing regarding #828376. >> >> Dennis, any objections if I NMU it with the attached debdiff or do you >> have something else in mind? >> >>> Thanks >>> Adrian >>> >> Sebastian > >> diff -Nru lcmaps-plugins-voms-1.6.2/debian/changelog >> lcmaps-plugins-voms-1.6.2/debian/changelog >> --- lcmaps-plugins-voms-1.6.2/debian/changelog 2014-01-20 >> 15:48:08.0 +0100 >> +++ lcmaps-plugins-voms-1.6.2/debian/changelog 2017-01-29 >> 21:51:50.0 +0100 >> @@ -1,3 +1,10 @@ >> +lcmaps-plugins-voms (1.6.2-2.1) unstable; urgency=medium >> + >> + * Non-maintainer upload. >> + * Get it built with openssl 1.1. (Closes: #828376). >> + >> + -- Sebastian Andrzej SiewiorSun, 29 Jan 2017 >> 21:51:50 +0100 >> + >> lcmaps-plugins-voms (1.6.2-2) unstable; urgency=low >> >>[ Mischa Salle ] >> diff -Nru lcmaps-plugins-voms-1.6.2/debian/patches/openssl11.patch >> lcmaps-plugins-voms-1.6.2/debian/patches/openssl11.patch >> --- lcmaps-plugins-voms-1.6.2/debian/patches/openssl11.patch 1970-01-01 >> 01:00:00.0 +0100 >> +++ lcmaps-plugins-voms-1.6.2/debian/patches/openssl11.patch 2017-01-29 >> 21:51:12.0 +0100 >> @@ -0,0 +1,20 @@ >> +Subject: workaround for openssl 1.1 >> + >> +X509 does not have ->name member anymore. It used to be the content of the >> +Subject property. Since it is only for higher debug I don't even try to >> fetch >> +the Subject property. >> +--- >> + src/voms/lcmaps_voms.c |2 +- >> + 1 file changed, 1 insertion(+), 1 deletion(-) >> + >> +--- a/src/voms/lcmaps_voms.c >> b/src/voms/lcmaps_voms.c >> +@@ -442,7 +442,7 @@ static int plugin_run_or_verify( >> + if ( ( px509_cred = lcmaps_cred_to_x509(cred) ) ) >> + { >> + lcmaps_log_debug(1,"%s: found X509 struct inside gss >> credential\n", logstr); >> +-lcmaps_log_debug(5,"%s: just for kicks: X509->name %s\n", >> logstr,px509_cred->name); >> ++/* lcmaps_log_debug(5,"%s: just for kicks: X509->name %s\n", >> logstr,px509_cred->name); */ >> + } >> + else >> + { >> diff -Nru lcmaps-plugins-voms-1.6.2/debian/patches/series >> lcmaps-plugins-voms-1.6.2/debian/patches/series >> --- lcmaps-plugins-voms-1.6.2/debian/patches/series 2013-11-12 >> 16:23:41.0 +0100 >> +++ lcmaps-plugins-voms-1.6.2/debian/patches/series 2017-01-29 >> 21:47:44.0 +0100 >> @@ -1,2 +1,3 @@ >> >> >> +openssl11.patch > > -- D.H. van Dok :: System administrator :: www.nikhef.nl/grid :: Phone +31 20 592 22 28 :: http://www.nikhef.nl/~dennisvd/
Bug#828376: OpenSSL: The LCMAPS/VOMS/Globus cluster
On 28-01-17 14:38, Adrian Bunk wrote: > Hi, > > #828375 lcmaps-plugins-verify-proxy: FTBFS with openssl 1.1.0 > #828376 lcmaps-plugins-voms: FTBFS with openssl 1.1.0 > > When trying to fix these FTBFS with OpenSSL 1.1 by switching LCMAPS to > 1.0.2 I end up also moving VOMS and Globus to OpenSSL 1.0.2 > > Is this the way to forward, or is there a better solution available > for lcmaps-plugins-verify-proxy and lcmaps-plugins-voms in stretch? It's not the way forward; globus has already been updated for openssl 1.1 and everything that uses it (voms, lcmaps) needs to be on the same version or there will be runtime mayhem. The fix for voms came just a few days ago, but now at least lcmaps-plugins-verify proxy should be fixed as well. If it's not in unstable yet it's there on Debian Mentors[1]. 1. https://mentors.debian.net/package/lcmaps-plugins-verify-proxy I've contacted our regular sponsor to upload it. Cheers, Dennis
Bug#820259: igtf-policy-classic: please make symlink location configurable and possible to disable them alltogether
On 07-04-16 04:09, Christoph Anton Mitterer wrote: > Package: igtf-policy-classic > Version: 1.73-1 > Severity: wishlist > > > Hi. > > Currently the package creates symlinks for all files in /etc/grid-security. > It would be nice if one could: > - disable this completely You can already. The debconf settings for the igtf-policy packages allow for two modes: - install all certificates by default, but exclude a list of hand-picked exceptions. - install none of the certificates by default, just the hand-picked ones. This can be done by running dpkg-reconfigure igtf-policy-classic Or pre-seeding debconf, e.g. igtf-policy-classic igtf-policy-classic/install_profile boolean false igtf-policy-classic igtf-policy-classic/include_ca multiselect NIKHEF > - configure the location where they're created Not sure if your request was meant as OR or AND; it's not hard to implement but the installation in /etc/grid-security/certificates is already a kludge. > The reasons are: > a) Even in grid environments, /etc/grid-security is no longer necessarily a >fixed location, e.g. dcache allows other locations for CA and voms stuff. Not sure if I understand this correctly. Couldn't dcache be told to look in /etc/grid-security/certificates? > b) The following scenario I use at our Tier-2: >- I basically want to have on location where I canonically set up the > trusted > CAs/voms files and where fetch CRL runs. >- all other nodes on the cluster, pull their files from that node, e.g. via > rsync, and deploy it to their respective /etc/grid-security (this is even > done like that by the host, where I keep the canonical repo of the certs. >Why? Well, several reasons: >- one central point where I can remove trusted CAs if I want to OK. >- one central point where fetch-crl runs, which has the minor benefit of > less services running on other nodes, and the major benefit, that it's > guaranteed that all nodes have the same CRLs. > It happens pretty often the the CRL servers fail sometimes and even if > they'd not, I'd want all nodes to have exactly the same CRLs (which is > not fully guaranteed if each of them runs fetch-crl, at possibly > different > times). > Accesses shouldn't be allowed on one node, but denied on another because > of different CRLs. I've not run into this sort of trouble at all; maybe it's worthwhile investigating why fetch-crl is not behaving as expected. Normally CRLs are fetched every 6 hours and they have a lifetime of a week, so complete failures due to CRL expiry are very rare. Your case can actually be covered by setting http_proxy on your nodes and setting up a dedicated caching proxy for the CRLs on the one node that keeps the canonical CRLs and CAs. See also http://wiki.nikhef.nl/grid/FetchCRL3 >Problems with the current way the package installs symlinks to > /etc/grid-security: >- They're all symlinks... so either I still have to install the package on > each node (which again makes it possible that they're out of sync) I *think* you can tell rsync to copy symlinks as files with -L. >- It doesn't work anymore, that the one node that holds the canonical > location > of my trusted CAs (which needs to be /etc/grid-security right now) pulls > his CAs via the same mechanism as all other nodes. I don't understand this. Wasn't this exactly the point of your setup? Cheers, Dennis
Bug#798283: clvmd: stack smashing detected -- solved
On Wed, 14 Oct 2015 16:35:17 +0200 Adi Kriegischwrote: > Hi! > > Do you have any plans to fix that bug for Jessie? If so, within what > timeframe? +1 the patch works and is trivial to apply. Dennis
Bug#788589: (no subject)
Done, the package is now available in backports as version 1.67-1~bpo8+1. See: https://packages.debian.org/source/jessie-backports/igtf-policy-bundle It seems this release won't automatically close bugs as mentioned in the changelog, so I'll do that manually. Regards, Dennis van Dok
Bug#784386: gnome-shell doesn't show applications from /var/lib/menu-xdg/applications/menu-xdg/
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06-05-15 02:04, Michael Biebl wrote: Please file a bug against gltron to provide a proper .desktop file. Already there: bug #737910. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJVSdvCAAoJEN/62Bl2F+8ZqgQP/iDi9kcGMPDlWauqb50VUW4P bDAHUxii6PwGexoGnCwIO0iihkbWUevo/6Cpv77pb4KQIg68ROT+T8kAGoRdULz+ 0ST8pZjYVCy0Wc5JJMssPKhNRZm3YyPRzZnDOwwbbjRkO0c8ws0A9RDq0a/t8tiH q9rjMdahlLWlZDkGzbOfjw+rzd1Pwy/+6/3ss/hOgvAvNuxokNPlJkJ6zRNHcNYo WJ45ENalPNfiJyhMgFudbZUe3zhGavmC5DOFmtY2r8byqd4p1LueAGDh4+xlYBhK DC2j9XPiSygXr6vuabYITbQJQcDmzqL2pfURlYuaKdf5+F0kcTgt6Sv1zrTSc/yQ IaNjPyhmJUKMKS1xTHQQ98UdX7d3QOc2TZ7odaxjgEhNnKpQJb1+LNlfhHA1T6yM vCgxpMxJpcZV+MTabJrbcg+4jO1WVsYiQJ+jvVnjc9sgOKwow3B68JAs7g050yJX OCYungMJ2M094KMG4OBN+iRMxGMlvvUzoSfBBxc4MO9RU8XqoNn7sQHlHc93RPU9 luFxqK2ksgu+FXaM8A85lz8tl4yw0s8Z9klREv5BZ/nZUlxBG+G3oXuAuf5S2zUu 589H84uIf8ABPg2gPq3kX1fG7hq4RFAYZGFF7xU/Tc/I+iQizWSgkwGxr3uMwwnk PQI7gb+eIM4oE2djm8c7 =l/RC -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#784386: gnome-shell doesn't show applications from /var/lib/menu-xdg/applications/menu-xdg/
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06-05-15 02:04, Michael Biebl wrote: Am 06.05.2015 um 00:51 schrieb Dennis van Dok: Shouldn't gnome shell be set up to read entries from /var/lib/menu-xdg/applications/menu-xdg as well? This is by design. What menu(-xdg) dumps there is basically unusable and makes a complete mess of the GNOME menu. So we decided to not show menu-xdg generated .desktop files. IIRC, KDE has gone the same way. OK, thanks for clearing that up. I couldn't find any information about how GNOME under Debian finds applications. Please file a bug against gltron to provide a proper .desktop file. It worked before, but now it's apparently broken. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJVSdqvAAoJEN/62Bl2F+8ZBzEP/ifdVeOqOgs2jEzLNdezxTeA reDgEwXWmqyAnslB+dQ5Pjaxy4beHVrxnbI72pM6LfxDAiRu559ies/ZY+iZfnmq ZfpRWnH7bDtArWAMCRpztFC1FeSalvRBWLBq3oXL/176rORowXyiiyGrmH18td0v Pik4OAZz8jOl9n1Ykty+eC0nDINxQpMga7EqOwQ6daIJhNhqGUbYGj3hW4ktogYY Qk2q86uwNPebWaEu++xLok8bokouUD7VA2oZ6+SCJz7eKkkjG7iB+rDe2rEekGff tz35dePS1Iyp0s/Bvd3QzQKiGn7g7A5ok/dz8Avl4gd4JIX+a6I8ndfiXm8ZNtpC /We0+ZrXF0elGYf8G9HlAxD/ybtavbQj3COoHjOwnJOrDgbtxdqiDc2p2auCx/WW YM4EoAdYcq0CQv6Kj4FIcCsGtyT2su4NnojPdXg+V8vBVzqx6ci46AFvcrZfbf8K KE5A5hckKSQVGUfsZrlMx6QNtncDWbgmJNf53s1XmwMl0BLMD7esreNEz520hdhc zb3tPswCA310ope0718cPAS8XJr4sfWhiqzyhPF5Qalwnvn96L2crenqLaSSzdd6 5soQGM1DmYU1KPrANAs537fzjakOdcmuScES3jlgscruwV5rfmSrBf+jD0wTbfGz X6vWRp34nFcDa6ceHSdq =u0ba -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#784386: gnome-shell doesn't show applications from /var/lib/menu-xdg/applications/menu-xdg/
Package: gnome-shell Version: 3.14.2-3+b1 Severity: normal Recently upgraded to Jessie. Gnome shell doesn't show applications that do not have a .desktop file in /usr/share/applications. For instance gltron. Not sure if this is a bug with gltron, but the menu-xdg package converts Debian menu entries to .desktop files. Shouldn't gnome shell be set up to read entries from /var/lib/menu-xdg/applications/menu-xdg as well? I couldn't find how to easily add my own applications to the list. -- System Information: Debian Release: 8.0 APT prefers stable APT policy: (500, 'stable'), (50, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-0.bpo.4-amd64 (SMP w/4 CPU cores) Locale: LANG=nl_NL.utf8, LC_CTYPE=nl_NL.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gnome-shell depends on: ii dconf-gsettings-backend [gsettings-back 0.22.0-1 ii evolution-data-server3.12.9~git20141128.5242b0-2+deb8u2 ii gir1.2-accountsservice-1.0 0.6.37-3+b1 ii gir1.2-atspi-2.0 2.14.0-1 ii gir1.2-caribou-1.0 0.4.15-1 ii gir1.2-clutter-1.0 1.20.0-1 ii gir1.2-freedesktop 1.42.0-2.2 ii gir1.2-gcr-3 3.14.0-2 ii gir1.2-gdesktopenums-3.0 3.14.1-1 ii gir1.2-gdm3 3.14.1-7 ii gir1.2-gkbd-3.0 3.6.0-1 ii gir1.2-glib-2.0 1.42.0-2.2 ii gir1.2-gnomebluetooth-1.03.14.0-2 ii gir1.2-gnomedesktop-3.0 3.14.1-1 ii gir1.2-gtk-3.0 3.14.5-1 ii gir1.2-ibus-1.0 1.5.9-1 ii gir1.2-mutter-3.03.14.2-1 ii gir1.2-networkmanager-1.00.9.10.0-7 ii gir1.2-nmgtk-1.0 0.9.10.0-2 ii gir1.2-pango-1.0 1.36.8-3 ii gir1.2-polkit-1.00.105-8 ii gir1.2-soup-2.4 2.48.0-1 ii gir1.2-telepathyglib-0.120.24.1-1 ii gir1.2-telepathylogger-0.2 0.8.1-1 ii gir1.2-upowerglib-1.00.99.1-3.2 ii gjs 1.42.0-1 ii gnome-backgrounds3.14.1-1 ii gnome-icon-theme-symbolic3.12.0-1 ii gnome-settings-daemon3.14.2-3 ii gnome-shell-common 3.14.2-3 ii gnome-themes-standard3.14.2.2-1 ii gsettings-desktop-schemas3.14.1-1 ii libatk-bridge2.0-0 2.14.0-2 ii libatk1.0-0 2.14.0-1 ii libc62.19-18 ii libcairo21.14.0-2.1 ii libcanberra-gtk3-0 0.30-2.1 ii libcanberra0 0.30-2.1 ii libclutter-1.0-0 1.20.0-1 ii libcogl-pango20 1.18.2-3 ii libcogl201.18.2-3 ii libcroco30.6.8-3+b1 ii libdbus-glib-1-2 0.102-1 ii libecal-1.2-16 3.12.9~git20141128.5242b0-2+deb8u2 ii libedataserver-1.2-183.12.9~git20141128.5242b0-2+deb8u2 ii libgcr-base-3-1 3.14.0-2 ii libgdk-pixbuf2.0-0 2.31.1-2+b1 ii libgirepository-1.0-11.42.0-2.2 ii libgjs0e [libgjs0-libmozjs-24-0] 1.42.0-1 ii libglib2.0-0 2.42.1-1 ii libgstreamer1.0-01.4.4-2 ii libgtk-3-0 3.14.5-1 ii libical1a1.0-1.3 ii libjson-glib-1.0-0 1.0.2-1 ii libmozjs-24-024.2.0-2 ii libmutter0e 3.14.2-1 ii libnm-glib4 0.9.10.0-7 ii libnm-util2 0.9.10.0-7 ii libpango-1.0-0 1.36.8-3 ii libpangocairo-1.0-0 1.36.8-3 ii libpolkit-agent-1-0 0.105-8 ii libpolkit-gobject-1-00.105-8 ii libpulse-mainloop-glib0 5.0-13 ii libpulse05.0-13 ii libsecret-1-00.18-1+b1 ii libstartup-notification0 0.12-4 ii libsystemd0 215-17 ii libtelepathy-glib0 0.24.1-1 ii libx11-6 2:1.6.2-3 ii libxfixes3 1:5.0.1-2+b2 ii mutter 3.14.2-1 ii python 2.7.9-1 ii telepathy-mission-control-5 1:5.16.3-1 Versions of packages gnome-shell recommends: ii gdm3
Bug#781081: proxy to help reproduce the issue
It may be hard to reproduce the problem, as not everyone has direct access to a VOMS server. So I attach a voms proxy sans key, which may be used to trigger the bug. Running voms-proxy-info -file vomsproxy-no-key *should* yield an error message (since the key is missing) but crashes with the latest openssl. HTH, Dennis -BEGIN CERTIFICATE- MIIKZzCCCdCgAwIBAgICEhwwDQYJKoZIhvcNAQELBQAwXjESMBAGA1UEChMJZHV0 Y2hncmlkMQ4wDAYDVQQKEwV1c2VyczEPMA0GA1UEChMGbmlraGVmMRcwFQYDVQQD Ew5EZW5uaXMgdmFuIERvazEOMAwGA1UEAxMFcHJveHkwHhcNMTUwMzI0MTEwNDE0 WhcNMTUwMzI0MjMwMzMwWjBuMRIwEAYDVQQKEwlkdXRjaGdyaWQxDjAMBgNVBAoT BXVzZXJzMQ8wDQYDVQQKEwZuaWtoZWYxFzAVBgNVBAMTDkRlbm5pcyB2YW4gRG9r MQ4wDAYDVQQDEwVwcm94eTEOMAwGA1UEAxMFcHJveHkwgZ8wDQYJKoZIhvcNAQEB BQADgY0AMIGJAoGBAKrXrlFVWq/h4NCwbvj8ACrCskJFf/MV2ZOJOja2VTyH+chD QKEeeGCpC3BfVOUkTqNwCDsWGN/1h4jNr64VCwVlnD5kbCZgvRbfd7eIDFRy3e8z XfeuLeETkXR+mvJOoX1ghK/nQqplWmgqoz8/Jn1XPgDBt8aVqK4HPtXBRNrfAgMB AAGjgggiMIIIHjAOBgNVHQ8BAf8EBAMCBLAwgggKBgorBgEEAb5FZGQFBIIH+jCC B/YwggfyMIIH7jCCBtYCAQEwWqBYMFKkUDBOMRIwEAYDVQQKEwlkdXRjaGdyaWQx DjAMBgNVBAoTBXVzZXJzMQ8wDQYDVQQKEwZuaWtoZWYxFzAVBgNVBAMTDkRlbm5p cyB2YW4gRG9rAgISHKBYMFakVDBSMRIwEAYDVQQKEwlkdXRjaGdyaWQxDjAMBgNV BAoTBWhvc3RzMRAwDgYDVQQLEwdzYXJhLm5sMRowGAYDVQQDExF2b21zLmdyaWQu c2FyYS5ubDANBgkqhkiG9w0BAQUFAAIRAPHLQ8tcoktZtH33qcFzj5MwIhgPMjAx NTAzMjQxMTA0MTNaGA8yMDE1MDMyNDIzMDQxM1owWTBXBgorBgEEAb5FZGQEMUkw R6Ahhh9wdmllcjovL3ZvbXMuZ3JpZC5zYXJhLm5sOjMwMDAwMCIEIC9wdmllci9S b2xlPU5VTEwvQ2FwYWJpbGl0eT1OVUxMMIIFeDCCBUgGCisGAQQBvkVkZAoEggU4 MIIFNDCCBTAwggUsMIIEFKADAgECAgISLDANBgkqhkiG9w0BAQUFADBSMQswCQYD VQQGEwJOTDEPMA0GA1UEChMGTklLSEVGMTIwMAYDVQQDEylOSUtIRUYgbWVkaXVt LXNlY3VyaXR5IGNlcnRpZmljYXRpb24gYXV0aDAeFw0xNDA0MTQwMDAwMDBaFw0x NTA0MTQxNDQ2MjNaMFIxEjAQBgNVBAoTCWR1dGNoZ3JpZDEOMAwGA1UEChMFaG9z dHMxEDAOBgNVBAsTB3NhcmEubmwxGjAYBgNVBAMTEXZvbXMuZ3JpZC5zYXJhLm5s MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtlaKlnwD2EBSWMfyAKdV bDerNK4KCYmU6RUXx6ISwk2UoiyEpQ9fnVhl53o0wyhaw3oUB0IpiQdudnOzWLzd 5YtlVaWiUTKUeMVFtf3vnNF3NVtPFb1rx2d1jHqa4/kkPh/OIDsMk/vWjd4PAaG+ UR+46zqn+NkFpH8FA8ntK+cfyq8Hw6sarNtMA7eyBr+kw3pkHOsnSG7VO19eFJX3 Tb5t8GRvwH+Ix2Ji/m36uSLUFFc3VycBvRRmFtLx7zBUYPntSZ5af5CHb/EA5xbL P1uz0lXt14aB4vVcgLjMf5OTgchCF1+TyJwcTi1AZlE/d/4wbs5pBVgnDfQqJdWN lQIDAQABo4ICCjCCAgYwDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBLAwJwYD VR0lBCAwHgYIKwYBBQUHAwEGCCsGAQUFBwMCBggrBgEFBQcDBDA4BgNVHR8EMTAv MC2gK6AphidodHRwOi8vY2EuZHV0Y2hncmlkLm5sL21lZGl1bS9jYWNybC5kZXIw KAYDVR0gBCEwHzAPBg0rBgEEAdFCBAICAQMCMAwGCiqGSIb3TAUCAgEwHwYDVR0j BBgwFoAUWwU6mcbVIr39lID8EajQ8XHWS6QwHQYDVR0OBBYEFNJtH4+8L0iEJf3j +S2XzuTaYvhWMBEGCWCGSAGG+EIBAQQEAwIF4DA0BglghkgBhvhCAQgEJxYlaHR0 cDovL2NhLmR1dGNoZ3JpZC5ubC9tZWRpdW0vcG9saWN5LzCBngYJYIZIAYb4QgEN BIGQFoGNRUVDIGlzc3VlZCB1bmRlciBwb2xpY3kgdmVyc2lvbiAzLjIgLSBsaW1p dGVkIGxpYWJpbGl0aWVzIGFwcGx5LCBzZWUgaHR0cDovL2NhLmR1dGNoZ3JpZC5u bC9tZWRpdW0vcG9saWN5LyAtIENlcnRpZmljYXRlIFRhZzogZjdiNGM2ZWYtYjY1 NjhhMC8GA1UdEQQoMCaCEXZvbXMuZ3JpZC5zYXJhLm5sghF2b21zLmdyaWQuc2Fy YS5ubDANBgkqhkiG9w0BAQUFAAOCAQEAEIS9k0JcHsmvdhkbXPJSTPAO04Azonvu 3VXBpfBmmI/RDfBJU/hGHPhN8rxeQQAci8kHDKkQDktUxAkROApu/hGecsBgRkn3 Yzl0vl9P5+KLbTjysHyQ3IEOnvp+eDSSDfZbeDsq/vgJYpTEzsHzNtTpmNmFBrya Axvz94+XbQAXeXp3/GJGail0rYSss+bOoI4qr3b92WflSmiMd4i2IFNPZX8yX34n fVnL5VMqt19dzHGyW+DSXkxpT/jyJ4EVlqjxKYaZcm9T+6zc71Y6IRPwbWd1B8ZS y/7dZa7USWW6c8Nk9Jrj/XrMOfbdVuAugKqg8t+mC8ClCgrC0IKExDAJBgNVHTgE AgUAMB8GA1UdIwQYMBaAFNJtH4+8L0iEJf3j+S2XzuTaYvhWMA0GCSqGSIb3DQEB BQUAA4IBAQAypWB3nH1HMk5zFs0Us/RGR4LSuDOAy/dtwdH1gm2UgZAwcyAJeTxN durKlpRkB2Vcl88kS471/W+sUF6bHlYiCnOeWQyh1u2lMfEdgf+OvhuS0rA8MV91 LMBBDpgPlq9h4yFzDyIyEosTDOmfk4M85sV4egB6qncUjaYNUwCcTSuTpdNZ6pYs eOUx99Qg/J743Bn2HUOhYksUivUTyO3irDB25mIsJfhD7Zw84b6VS8mQIKLScwpM uYyLAt1I0L/unq9g0IAp+hT/gz9iW7d3qc30U41h31cVqaqYhOI142dU3GddNoZS jzjg28H2ilvQ+kW1Ncd1VAfsdwh5jnYHMA0GCSqGSIb3DQEBCwUAA4GBAJxBv0lz muoPtXnbECldyuVRvxuCKRrJOtioUZRcp5O5anBiHzxmzdkJ5q9FjyfMnfKVRHap jr3+THRDticzKhOGz0XU7elRw4Kh+r+nrU/h/iIMox7+j2f7yFrJMCka8hhp7h6G erdQRV15H4PNeZ5GFgTOzNkie1sLQhAqye0K -END CERTIFICATE- -BEGIN CERTIFICATE- MIIC1TCCAb2gAwIBAgICEhwwDQYJKoZIhvcNAQELBQAwTjESMBAGA1UEChMJZHV0 Y2hncmlkMQ4wDAYDVQQKEwV1c2VyczEPMA0GA1UEChMGbmlraGVmMRcwFQYDVQQD Ew5EZW5uaXMgdmFuIERvazAeFw0xNTAzMjQxMDU4MzBaFw0xNTAzMjQyMzAzMzBa MF4xEjAQBgNVBAoTCWR1dGNoZ3JpZDEOMAwGA1UEChMFdXNlcnMxDzANBgNVBAoT Bm5pa2hlZjEXMBUGA1UEAxMORGVubmlzIHZhbiBEb2sxDjAMBgNVBAMTBXByb3h5 MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC64OgbUTG3cq6fKPZ6p1Qnh5mh X+AyjQYzTp6IOjMU6PaWe3HBuBeDdFZYVACxL1GI3YHsETZN7jxTRslIzBmzDo1H Wn+4FO9JYsW2kUqQhGcT4PSWuxEzLyt7YFzekhvGTXOh6lYwYYXM+UNhdkymEegW RmI4Iq6qbd9+5T0fMwIDAQABozEwLzAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYB BQUHAwQwDgYDVR0PAQH/BAQDAgSwMA0GCSqGSIb3DQEBCwUAA4IBAQBf5zuX4h74 F9H3wPjXzcw29mKISoSxGs7SaHbXNryoy/GXbD2SSkXLEVz/IQDj7d/1sKHMnzMf asxbOUC0WYm3kJXGLniVyuovaf0jjKOYN0RQR7NelHVcadySyJtR++fyeEYGSgxS RuU+N5WKthgYLDANK95NSmeqKwbSI/KqvH1NkwBCai6vpEu1oo+diBdx6GtksVVB fyKZdXejjuHNY+5hR2gZT5xKngIqFQcKnGFN9E9k02aBanB7F3vVWpI5QBSCX2r0 7tmpo3Pk2no10HU3f11IgFL1ttBTthoPKkLtlmZhnQJ8LMYJ1PGBaOj6DsUP6rNS
Bug#767993: igtf-policy-bundle: new upstream version
On 04-11-14 00:13, Christoph Anton Mitterer wrote: Source: igtf-policy-bundle Version: 1.59-1 Severity: wishlist Hey. 1.60 is out :) You can find it on mentors. I still need my sponsor to upload it (Mattias Ellert). I'm still in the process to become my own maintainer. CHeers, Dennis ---BeginMessage--- Hi. Your upload of the package 'igtf-policy-bundle' to mentors.debian.net was successful. Others can now see it. The URL of your package is: http://mentors.debian.net/package/igtf-policy-bundle The respective dsc file can be found at: http://mentors.debian.net/debian/pool/main/i/igtf-policy-bundle/igtf-policy-bundle_1.60-1.dsc If you do not yet have a sponsor for your package you may want to go to http://mentors.debian.net/sponsors/rfs-howto/igtf-policy-bundle and set the Seeking a sponsor option to highlight your package on the welcome page. You can also send an RFS (request for sponsorship) to the debian-mentors mailing list. Your package page will give your suggestions on how to send that mail. Good luck in finding a sponsor! Thanks, -- mentors.debian.net ---End Message---
Bug#763404: igtf-policy-bundle: perhaps fetch-crl should be just suggested
On 30-09-14 00:51, Christoph Anton Mitterer wrote: Source: igtf-policy-bundle Version: 1.58-1 Severity: minor Hi Dennis. I think I'd tend to only Suggest fetch-crl, rather then recommend. Agreed. From the Policy I understand that 'Recommends' means the combination is typically found together except for unusual cases. As I can't foresee what other use cases there might be, 'Suggests' is more appropriate. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745761: igtf-policy-bundle: General update after the debconf review process
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04-06-14 06:58, Christian PERRIER wrote: Dear Debian maintainer, Translators have been working hard and here is now the result of their efforts. [...] As said, please use *at least* the PO files as provided here, preferrably over those sent by translators in their bug reports. All of them have been checked and reformatted. In some cases, formatting errors have been corrected. I've reviewed the differences between the po files as originally sent, and in your attachment. I don't really understand what constitutes a formatting error. In some cases the strings in the po files were very wide, but in other cases the reformatting seemed to be rather arbitrary. It is now safe to upload a new package version with these changes. Please notify me of your intents with regards to this. On June 2, a new upstream release (1.57) came out. I've merged the translations with this update, and I intent to upload the new package ASAP but after at least some functional testing. The packaging is a bit out of the ordinary, as the templates.in file applies to several IGTF profile packages, and the normal flow of dh_installdebconf could not be used. I had to resort to manually running po2debconf on debian/templates.in in the rules file. I'm still in the process to become maintainer, and in the meantime I rely on my sponsor to upload the package for me. There is of course no hurry to update your package but feel free to contact me in case you would need sponsoring or any other action to fix this. If my usual sponsor doesn't respond in a reasonable timespan, I may take you up on your offer. Many thanks for all your efforts! Dennis van Dok -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBAgAGBQJTjwIbAAoJEN/62Bl2F+8Zox0P/0QAQhLaCOcVir+rWb126arH 098FfTivoX5yF+v5NukBhBDEntMC+z2ctmm2f0nwQvMWi9Bil9znQb2zIAKLBnsA ec5X7MHk3fX9MsxnFeZfeEsRXlSbgFeb3/HMUU6GvfVd7OJ2lxvNnWZtQ255ZbDS 2ia17ydvd4FyrZT+ZfMak2Z/v/BdScNGE/OPyUkahpB7Nxle1sDt8R+OaUIjHL6a FKXOFYb/xOayCkHOnEWkfWdr37WXMzDgCN8u7CK0FD5ScQp1cSBqdpSP7SvLPEUm c1yThl1JwSqTA8n77Pm6nysFZe/gG2lzsdkD3TTKCaSJjvlHLKq8izd1iah8+xz1 Yd0I0ERCoHIRGPETefisiPNIXhe9vDT+SDCZyjflOk8XTMhIScesWrAT50/q9maC CpqlM6Cvk3ncfz+OuUbfWdKU1v0oKYmxj5MsqxUXwHZTy0AOpeCFL5+0soBFKgqT OdNZpBP2l3CKceL/Sdc9Soq8HZpqCg+R+3V4fXfBXMccChXj3gnBLbvs/LDlz57e 3/DmGvOCnwCHAlt9Uc54xwzWlZGF8juXkZbjMQ6lgdeeW+A99f8uKYXUZ9APvDr5 St2aml6FDuMT3ZEtNU3u/cdRsyxLSeaO8WVfkKpRNPTPdYA16G0KanmFTUoeKlOJ hy3+zoE8QOePR252LKho =X95Q -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745761: [RFR] templates://igtf-policy-bundle/{templates.in}
On 29-04-14 21:48, Justin B Rye wrote: The International Grid Trust Federation (IGTF) maintains a common There's another confusing issue here: http://www.igtf.net/ says the IGTF is the InterOPERABLE GLOBAL Trust Federation. On the other hand, the organisation's charter definitely calls it the InterNATIONAL GRID Trust Federation. Has it officially changed? I just learned that the IGTF is in transition. They try to de-GRID-ify their name, and turn IGTF into a brand name rather than an acronym. Apparently this is a common theme in such organisations, but I invite David Groep (current chair of the IGTF) to comment about the rationale of this transition. It must have something to do with the fact that 'Grid' as a buzzword is past its prime. So we could stay one step ahead of things by changing the description altogether and leaving out the acronymic expansion. What do you think? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745761: [ITR] templates://igtf-policy-bundle/{templates.in}
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 29-04-14 06:46, Christian PERRIER wrote: I will act as the coordinator of this activity for igtf-policy-bundle. The first step of the process is to review the debconf source template file(s) of igtf-policy-bundle. This review will start on Friday, May 02, 2014, or as soon as you acknowledge this mail with an agreement for us to carry out this process. OK, please go ahead! - --Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBAgAGBQJTX2atAAoJEN/62Bl2F+8ZbR8P/Rle+5F7LTnMdKtjH9Y+CSju jSzCa+hwi1KzzAY/qDQmrZQD6DQVvobcV+XvuKwSXIw1ZhKbOYnwnCewNpAGSCuD xrPy+nwTR1ogpI+QMoVWUY3g7F3U94+EIM8qUG9vIevIqmR5adPxRlOra11gHsuH w8IjGmuu1cFFbfrIoL8OAxg3A/0MDqPGjpNqDJp05YWOlVfllXcQ87RCuX4iZh6R wWMsjJLlMTxLsldZlwR8pB48qAqOOALfDSunn/McC7Rd8UNnPT877WTRZNejdq/L /qYaspcF+gTccfBxcvl/53gI1w9I/6q4Pvn29Iat6QnKal8/cwqIP1BylelLDoVn VYXXuCFEUexCMMJ6t82ovbhBtN9Tgxh1C6xPYumTU4tFp7gfyjsvSPqKkFKmw/wy 89IVEgK6HIMEA6gdYRt9LPulAYdvYtBSeWP/01aySysKhD5tVlDoP1FtXAZ5feAe qi1SZEfsYA3fzENTCFRCKtTP227L61grt91FNg+5EOvLXrG+q2dp8aqV83LNTD1s XSNwPSKpDOSyhXEoxyk5vmuO0IIlOetkj9zgdPfjZVFKhI2IJyNFeq9pjfHMjwTO xKo5cLN+tb5Z1yUGrQHyxGmEGAydZzrNR73QdHnt59pK61YxS2XEHEwsLlztTcTH 8CHvBtsD2meUbJTAStfs =Cq6t -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745761: [RFR] templates://igtf-policy-bundle/{templates.in}
On 29-04-14 21:48, Justin B Rye wrote: I suspect you'll see a second draft of this... Christian PERRIER wrote: Rationale: --- igtf-policy-bundle.old/debian/templates.in 2014-04-24 08:41:06.143267631 +0200 +++ igtf-policy-bundle/debian/templates.in 2014-04-29 19:07:52.910508550 +0200 @@ -1,23 +1,27 @@ Template: igtf-policy-@PROFILE@/install_profile Type: boolean Default: true -_Description: Install the IGTF @PROFILE@ CAs in /etc/grid-security/certificates? - This package installs the IGTF CAs in /etc/grid-security/certificates. - There are two ways to deal with these certificates: - - yes: install all, except those in the exclude list - - no: install only CAs in the include list. - The include/exclude lists are covered by the next question. +_Description: Install the IGTF @PROFILE@ CA certificates in /etc/grid-security/certificates? This could get a bit long if the profiles can have names like unaccredited (looks like they can). Actually, the only profiles now are classic, MICS and SLCS, with IOTA in the pipe-line (but no CAs yet). Unaccredited and experimental are not profiled and not handled through debconf. Does it really need to specify the install path here? I'd suggest moving that to the long description only. I agree it's getting long, but it is the most accurate. Asking the user to trust the CAs is less direct and may lead to some confusion about what that trust entails. And the long description should probably also mention the effect produced by putting the files in this location (that is, it means they're trusted). + This package installs the IGTF Certification Authority certificates in /etc/grid-security/certificates. Maybe: Please specify whether the IGTF Certification Authority certificates for the @PROFILE@ profile should be installed as trusted in /etc/grid-security/certificates. Somehow installed as trusted feels like it might mean more than just installed, where it is really installed, and therefore trusted. It's the ambiguity of the language I guess. + . + If you choose this option, all certificates will be installed, except + those in the exclude list. + . + If you do not choose this option, only + certificates from the include list will be installed. + . + You will then have the opportunity to define the relevant list. Wait, wait, wait. Is that what the original is saying? I thought it was just asking whether the files should be installed (after all, that's what the question in the synopsis asks), with a secondary warning that there would be some sort of subsequent question about whether the default policy should be inclusive or exclusive. But sure enough, there doesn't seem to *be* any such follow-up question. Actually this is what I originally meant, and I agree with the rephrasing. I was thinking it could be boiled down to a single sentence along the lines of (deciding) whether certificates should be included by default unless explicitly excluded, or vice versa. But perhaps that might be too compressed. But that is the crux of the matter: whether to choose all but some or none but some. - Rephrasing the sentence mentioning the opportunity to tune lists should also avoid reference to the way the question will be asked. Il also made sure that CA is explained at least once. Rethinking what the actual question is... should it perhaps be _Description: Trust IGTF @PROFILE@ CAs by default? Trusted IGTF Certification Authority certificates are installed in /etc/grid-security/certificates. . Accept this option to have certificates included by default unless they are explicitly excluded. Reject it to choose the reverse policy, excluding them unless explicitly included. . You will then have the opportunity to define the list of exceptions. That's bang on, although I'm still not sure about the 'trust' in the synopsis. Meanwhile in the control file... Package: igtf-policy-classic [...] Description: IGTF classic profile for Authority Root Certificates I know what a Root Certificate Authority is, and I can imagine what a Root Authority Certificate might be, but what on earth is an Authority Root Certificate? Google shows me no hits that aren't either copies of this text or random chunks out of the middle of some longer string of nouns (usually Something Certificate Authority Root Certificate Something Somethings). I strongly suspect this is garbled and should be... um... CA Root Certificates, perhaps? Or just root certificates, since after all, that's what it calls them below... I think 'Certificate Authorities' is best. After all, not all these are in fact *Root* CAs. Some of them are intermediates. The International Grid Trust Federation (IGTF) maintains a common There's another confusing issue here: http://www.igtf.net/ says the IGTF is the InterOPERABLE GLOBAL Trust Federation. On the other hand, the organisation's
Bug#745677: found it
I found the cause of the failure. It is due to the glob in the remove_leftover_crls function. If the glob does not match any files (which is most likely the case on new installations), the loop variable contains an asterisk and the expansion of ${i%.*} will list all files in that directory. The globbing behaviour of sh is truly hairy. I'll have to find a way to see if the directory contains any .r0 files at all, and all the examples I find are pretty ugly. A temporary workaround is to install and run fetch-crl, which will populate the directory with r0 files. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745677: igtf-policy-classic: fails during installation
Hi Christoph, I'm baffled which call to basename would have this problem. I did spot a typo in /var/lib/dpkg/info/igtf-policy-classic.postinst on line 110, where I should have used a '%' instead of a '#', but this should not cause the error message. What is currently listed in your /etc/grid-security/certificates directory? Just traditional paranoia: could you try running with LANG=C LC_ALL=C? I tried several combinations of installation and configuration but I could not reproduce this. Dennis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736283: sponsorship-request: RFS: lcas/1.3.19-2 -- Fix for FTBFS bug
Package: sponsorship-request Severity: normal Dear mentors, I am looking for a sponsor for my package lcas * Package name: lcas Version : 1.3.19-2 Upstream Author : grid-mw-secur...@nikhef.nl * URL : http://wiki.nikhef.nl/grid/Site_Access_Control * License : Apache 2.0 Section : libs It builds those binary packages: lcas-interface - Local Centre Authorization Service API liblcas-dev - Local Centre Authorization Service development files liblcas0 - Local Centre Authorization Service runtime To access further information about this package, please visit the following URL: http://mentors.debian.net/package/lcas Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/l/lcas/lcas_1.3.19-2.dsc Changes since the last upload: * Adding build-depend on pkg-config (Closes: #730884) * Use dh-autoreconf instead of autotools-dev to also fix FTBFS on ppc64el by getting new libtool macros (still updates config.{sub,guess}). (Thanks Logan Rosen) LCAS and several other middleware packages fail to build from source with a recent update to the Globus Toolkit. By adding pkg-config to the build dependencies this is fixed. The same problem holds for the packages lcmaps-plugins-basic, lcmaps-plugins-verify-proxy, lcmaps-plugins-voms, lcmaps-plugins-jobrep, lcas-lcmaps-gt4-interface, and lcmaps. I would be very grateful if someone would upload these packages for me, as I'm still in the process of becoming a maintainer. Regards, Dennis van Dok -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702329: Updated RFS
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package igtf-policy-bundle * Package name: igtf-policy-bundle Version : 1.55-1 Upstream Author : David Groep * URL : http://dist.eugridpma.info/distribution/igtf/ * License : Apache 2 Section : misc It builds those binary packages: igtf-policy-classic - IGTF classic profile for Authority Root Certificates igtf-policy-experimental - IGTF experimental Authority Root Certificates igtf-policy-mics - IGTF MICS profile for Authority Root Certificates igtf-policy-slcs - IGTF SLCS profile for Authority Root Certificates igtf-policy-unaccredited - IGTF unaccredited Authority Root Certificates To access further information about this package, please visit the following URL: http://mentors.debian.net/package/igtf-policy-bundle Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/i/igtf-policy-bundle/igtf-policy-bundle_1.55-1.dsc More information about hello can be obtained from http://www.igtf.net/. Changes since the last upload: * New upstream release: - New root certificate with extended life time for NorduGrid CA 1f0e8352 (DK) - Updated contact metadata for all RENATER Grid-FR related CAs (FR) - Updated CRL URL and metadata for IHEP 2013 CA 39d30eba (CN) - New root certificates for NCSA CA re-key: MyProxy CA 2013 c36f6349/7aa2b7bd and Two Factor CA 2013 ca157cee/48c8f10a (US) - New root certificate for EGI catch-all CA SEEGRID-CA-2013 772dbd1c (GR) - Removed AIST Grid CA (JP) - Discontinued IUCC CA (6fee79b0) following migration to TCS (IL) - Suspended JUnet-CA (b3222f9e) (JO) - Removed expired unaccredited CAs (misc) - Added unaccredited worthless NL e-Infra Zero tutorial CA 338a3561 (NL) Regards, Dennis van Dok -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666229: updated to 1.55
Hi, just to let everyone know I'm still doing this. I've uploaded the latest release (1.55) and updated the RFS. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702329 Dennis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#730229: libmodule-starter-perl: $ExtUtils::MakeMaker::VERSION is not numeric in numeric ge
Package: libmodule-starter-perl Version: 1.580+dfsg-1 Severity: normal Tags: upstream patch When starting a fresh module with MakeMaker e.g. with module-starter --module Test -eumm --author John Doe --email j...@example.com The Makefile.PL contains a test: ($ExtUtils::MakeMaker::VERSION = 6.3002 ? ('LICENSE'= 'perl') : ()), However, the $ExtUtils::MakeMaker::VERSION is a string '6.57_05'. When running perl Makefile.PL it prints an error: Argument 6.57_05 isn't numeric in numeric ge (=) at Makefile.PL line 6. The solution is to use Revision instead of VERSION. I'll attach a patch. It doesn't seem to affect the generated Makefile on my system. -- System Information: Debian Release: 7.2 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.10-2-amd64 (SMP w/4 CPU cores) Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libmodule-starter-perl depends on: ii libpath-class-perl 0.26-1 ii perl5.14.2-21+deb7u1 libmodule-starter-perl recommends no packages. libmodule-starter-perl suggests no packages. -- no debconf information --- a/lib/Module/Starter/Simple.pm +++ b/lib/Module/Starter/Simple.pm @@ -524,7 +524,7 @@ AUTHOR = q{$author}, VERSION_FROM= '$main_pm_file', ABSTRACT_FROM = '$main_pm_file', -(\$ExtUtils::MakeMaker::VERSION = 6.3002 +(\$ExtUtils::MakeMaker::Revision = 63002 ? ('LICENSE'= '$self-{license}') : ()), PL_FILES= {},
Bug#720179: squeak-plugins-scratch: scratch crashes (exit code = 255) when trying to use the webcam
Package: squeak-plugins-scratch Version: 1.4.0.2~svn.r83-2 Severity: normal Steps to reproduce: - start scratch on the command line in a terminal (to capture output) it opens with a default new project with a single sprite (the scratch cat) - in the middle pane sprite1 can be edited: click on the costumes tab this shows the two costumes of the sprite and several buttons to create a new costume (paint, import, camera). - click on 'camera' In my case, the light indicating that the webcam is turned on briefly flashes, and the scratch program ends. The output of the program is below, the exit code is 255. Executing: /usr/lib/squeak/4.10.2-2614/squeakvm -encoding UTF-8 -vm-display-x11 -plugins /usr/lib/scratch/plugins/:/usr/lib/squeak/4.10.2-2614/ -vm-sound-pulse /usr/share/scratch/Scratch.image Recursive not understood error encountered 14178232 BitBltsetDestForm: 14178128 BitBlt classtoForm: 14177896 WarpBlt classtoForm: 14177804 ScratchCameraDialogstep 13562096 ScratchCameraDialogopenCamera 13397580 ScriptableScratchMorphtakePhoto 13397720 [] in SimpleButtonMorphdoButtonAction 13397488 CursorshowWhile: 13397396 SimpleButtonMorphdoButtonAction 13397304 ResizableToggleButton2mouseUp: 13397212 HandMorphhandleMouseUp: 13397120 HandMorphhandleEvent: 13397028 HandMorphprocessEvents 13396844 [] in PasteUpMorphdoOneCycleNow 13396936 SequenceableCollectiondo: 13396752 PasteUpMorphhandsDo: 13396660 PasteUpMorphdoOneCycleNow 13396568 PasteUpMorphdoOneCycle 4959436 [] in ProjectspawnNewProcess 4959528 [] in BlockContextnewProcess -- System Information: Debian Release: 7.1 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.9-1-amd64 (SMP w/4 CPU cores) Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages squeak-plugins-scratch depends on: ii libc6 2.17-92 ii libcairo2 1.12.2-3 ii libglib2.0-0 2.33.12+really2.32.4-5 ii libpango1.0-0 1.30.0-1 Versions of packages squeak-plugins-scratch recommends: ii udev 175-7.2 Versions of packages squeak-plugins-scratch suggests: ii squeak-plugins-scratch-dbg 1.4.0.2~svn.r83-2 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702329: [UPDATE] RFS: igtf-policy-bundle/1.54-1 [ITP] -- The International Grid Trust Federation CA distribution
Dear mentors, this is to let you know I've updated the igtf-policy-bundle package on mentors.debian.org. I would be very grateful it someone would sponsor this package, or generally give feedback. * Package name: igtf-policy-bundle Version : 1.54-1 Upstream Author : David Groep dav...@nikhef.nl * URL : http://dist.eugridpma.info/distribution/igtf/ * License : Apache 2 Section : misc It builds those binary packages: igtf-policy-classic - IGTF classic profile for Authority Root Certificates igtf-policy-experimental - IGTF experimental Authority Root Certificates igtf-policy-mics - IGTF MICS profile for Authority Root Certificates igtf-policy-slcs - IGTF SLCS profile for Authority Root Certificates igtf-policy-unaccredited - IGTF unaccredited Authority Root Certificates To access further information about this package, please visit the following URL: http://mentors.debian.net/package/igtf-policy-bundle Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/i/igtf-policy-bundle/igtf-policy-bundle_1.54-1.dsc More information about the IGTF distribution can be obtained from http://www.igtf.net/ Changes since the last upload: * New upstream release: - Extended life time of Grid-KA CA (dd4b34ea) (DE) - Added new CERN hierarchy for CERN IT/IS CA (SHA2 migration) (CH) - Updated metadata for GridGermany DFN-CERT CAs (DE) - Updated contact metadata for KEK (JP) - Updated contact metadata for HKU (HK) - Updated contact metadata for AIST (JP) Regards, Dennis van Dok -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702329: RFS update
Dear mentors, I am once again looking for a sponsor for my package igtf-policy-bundle * Package name: igtf-policy-bundle Version : 1.53-1 Upstream Author : David Groep dav...@nikhef.nl * URL : http://dist.eugridpma.info/distribution/igtf/ * License : Apache 2 Section : misc It builds those binary packages: igtf-policy-classic - IGTF classic profile for Authority Root Certificates igtf-policy-experimental - IGTF experimental Authority Root Certificates igtf-policy-mics - IGTF MICS profile for Authority Root Certificates igtf-policy-slcs - IGTF SLCS profile for Authority Root Certificates igtf-policy-unaccredited - IGTF unaccredited Authority Root Certificates To access further information about this package, please visit the following URL: http://mentors.debian.net/package/igtf-policy-bundle Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/i/igtf-policy-bundle/igtf-policy-bundle_1.53-1.dsc More information about the igtf CA distribution can be obtained from http://www.igtf.net/ Changes since the last upload: * New upstream version This package contains a collection of CAs that are not in the ca-certificates package, but which are regularly used in the context of grid computing. The IGTF bundles the forces of three policy management authorities, the EUGridPMA, the TAGPMA and APGridPMA. The packages are bundled according to the profiles defined by the IGTF. I've implemented integration with the ca-certificates packages and admins can choose to whitelist or blacklist certain CAs. Regards, Dennis van Dok -- D.H. van Dok :: Software Engineer :: www.nikhef.nl/grid :: Phone +31 20 592 22 28 :: http://www.nikhef.nl/~dennisvd/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702329: RFS update
On 20-06-13 13:04, Ansgar Burchardt wrote: Hi, I don't plan to sponsor this package, but here is one comment: On 06/20/2013 11:34, Dennis van Dok wrote: igtf-policy-classic - IGTF classic profile for Authority Root Certificates igtf-policy-experimental - IGTF experimental Authority Root Certificates igtf-policy-mics - IGTF MICS profile for Authority Root Certificates igtf-policy-slcs - IGTF SLCS profile for Authority Root Certificates igtf-policy-unaccredited - IGTF unaccredited Authority Root Certificates Why are these multiple binary packages? I would assume they should just be installed into different locations. The full collection contains certificates for CAs that are not accredited (yet), so typically you don't want them installed at all. The distinction between classic, MICS (member-integrated) and SLCS (short-lived credentials) is the profile as defined by the IGTF. The admin should be aware of the differences in these policies. Although there is an option to exclude certain CAs from being trusted, the default is to trust all (accredited) CAs that are installed. A sponsor should check the integrity of the certificates. How could he do this? I can bring the sponsor in personal contact with David Groep, who is a member of the IGTF and upstream distributor. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#712685: stdsoap2.h: struct soap should match exactly with what libgsoap uses
Package: gsoap Version: 2.8.12-1 Severity: normal Tags: upstream gsoap installs stdsoap2.h (it is in package libgsoap-dev), with no changes from the sources. This file contains many #ifdef ... #endif constructs to select features. This file is used at build time of libgsoap.so; one of the datastructures in this library is called struct SOAP_STD_API soap. Depending on the use of the WITH_IPV6 flag, the size of one of its fields differs: #ifdef WITH_IPV6 struct sockaddr_storage peer; /* IPv6: set by soap_accept and by UDP recv */ #else struct sockaddr_in peer; /* IPv4: set by soap_connect/soap_accept and by UDP recv */ #endif Applications that build and link to libgsoap *must* match this choice exactly, at the risk of misaligning the fields of struct soap which could result in crashes. This also leads to potential security vulnerabilities. It is particulary unsafe to forget -DWITH_IPV6 when building against libgsoap.so. The choices for libgsoap are recorded in the pkgconfig files (gsoap.pc), but rather than relying on pkgconfig, it would seem safer to install a version of stdsoap2.h that fixes all such choices according to what was chosen for libgsoap.so. If pkgconfig is the only way to go, a dependency on pkg-config should probably be included. Best, Dennis van Dok -- System Information: Debian Release: 7.0 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.9-1-amd64 (SMP w/4 CPU cores) Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gsoap depends on: ii libc6 2.13-38 ii libgcc1 1:4.7.2-5 ii libgsoap-dev 2.8.12-1 ii libgsoap3 2.8.12-1 ii libstdc++64.7.2-5 gsoap recommends no packages. gsoap suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#710378: RFP: libevhtp -- libevent based HTTP API
Package: wnpp Severity: wishlist * Package name: libevhtp Version : 1.2.0 Upstream Author : Mark Ellzey soc...@gmail.com * URL : https://github.com/ellzey/libevhtp * License : BSD-3-Clause Programming Lang: C Description : libevent based HTTP API Libevent's http interface was created as a JIT server, never meant to be a full-fledged HTTP service. This library attempts to improve on that. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702708: openssh-client: ssh-agent aborts quietly when ssh-askpass is not installed
Package: openssh-client Version: 1:6.0p1-4 Severity: normal Dear Maintainer, I'm using xfce and did not have ssh-askpass installed. When I tried to add my key to ssh-agent with the '-c' flag (to force asking confirmation for using the key) and subsequently using the key, it admitted failure to use the key. Later attempts to connect to the agent failed (with ssh-add -l); the socket was gone. The syslog (/var/log/auth.log) shows: Mar 10 13:04:05 rowlf ssh-agent[6160]: fatal: ssh_askpass: exec(/usr/bin/ssh-askpass): No such file or directory And a trace of the ssh-agent process shows it actually quits: 6240 execve(/usr/bin/ssh-askpass, [/usr/bin/ssh-askpass, Allow use of key /home/user/.ssh...], [/* 34 vars */]) = -1 ENOENT (No such file or directory) 6240 time([1362917645])= 1362917645 6240 open(/etc/localtime, O_RDONLY) = 5 6240 fstat(5, {st_mode=S_IFREG|0644, st_size=2917, ...}) = 0 6240 fstat(5, {st_mode=S_IFREG|0644, st_size=2917, ...}) = 0 6240 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8b6ab3c000 6240 read(5, TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\r\0\0\0\r\0\0\0\0..., 4096) = 2917 6240 lseek(5, -1843, SEEK_CUR) = 1074 6240 read(5, TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\16\0\0\0\16\0\0\0\0..., 4096) = 1843 6240 close(5) = 0 6240 munmap(0x7f8b6ab3c000, 4096) = 0 6240 socket(PF_FILE, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 5 6240 connect(5, {sa_family=AF_FILE, path=/dev/log}, 110) = 0 6240 sendto(5, 34Mar 10 13:14:05 ssh-agent[62..., 110, MSG_NOSIGNAL, NULL, 0) = 110 6240 close(5) = 0 6240 unlink(/tmp/ssh-EGHqx1HqHD8i/agent.6231) = 0 6240 rmdir(/tmp/ssh-EGHqx1HqHD8i)= 0 6240 exit_group(255) = ? 6232 ... read resumed , 1023) = 0 6232 --- SIGCHLD (Child exited) @ 0 (0) --- I'm not sure what the bug is here; either it's a dependency issue (since ssh-agent clearly expect ssh-askpass), but it could also be addressed by better feedback to the user about the situation. E.g. instead of Agent admitted failure to sign using the key. say The agent could not ask for confirmation and has quit. But I'm not sure how the protocol works; it may be hard to pass such data. -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages openssh-client depends on: ii adduser3.113+nmu3 ii debconf [debconf-2.0] 1.5.49 ii dpkg 1.16.9 ii libc6 2.13-38 ii libedit2 2.11-20080614-5 ii libgssapi-krb5-2 1.10.1+dfsg-4 ii libselinux12.1.9-5 ii libssl1.0.01.0.1e-1 ii passwd 1:4.1.5.1-1 ii zlib1g 1:1.2.7.dfsg-13 Versions of packages openssh-client recommends: ii openssh-blacklist0.4.1+nmu1 ii openssh-blacklist-extra 0.4.1+nmu1 ii xauth1:1.0.7-1 Versions of packages openssh-client suggests: pn keychain none pn libpam-sshnone pn monkeysphere none ii ssh-askpass 1:1.2.4.1-9 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702328: RFS: lcmaps-plugins-jobrep/1.5.2-1 -- job repository plugin for the LCMAPS framework
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package lcmaps-plugins-jobrep * Package name: lcmaps-plugins-jobrep Version : 1.5.2-1 Upstream Author : MW security developers at Nikhef grid-mw-secur...@nikhef.nl * URL : https://wiki.nikhef.nl/grid/LCMAPS * License : Apache 2 Section : libs It builds those binary packages: lcmaps-plugins-jobrep - Jobrepository plugin for the LCMAPS authorization framework lcmaps-plugins-jobrep-admin - Jobrepository database setup tools To access further information about this package, please visit the following URL: http://mentors.debian.net/package/lcmaps-plugins-jobrep Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/l/lcmaps-plugins-jobrep/lcmaps-plugins-jobrep_1.5.2-1.dsc More information about hello can be obtained from http://www.example.com. Changes since the last upload: * New upstream release (closes: #701555) This release closes a bug about bashishms in the admin tools. Regards, Dennis van Dok -- D.H. van Dok :: Software Engineer :: www.nikhef.nl/grid :: Phone +31 20 592 22 28 :: http://www.nikhef.nl/~dennisvd/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702329: RFS: igtf-policy-bundle/1.52-1 [ITP] -- The International Grid Trust Federation CA distribution
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package igtf-policy-bundle * Package name: igtf-policy-bundle Version : 1.52-1 Upstream Author : David Groep dav...@nikhef.nl * URL : http://dist.eugridpma.info/distribution/igtf/ * License : Apache 2 Section : misc It builds those binary packages: igtf-policy-classic - IGTF classic profile for Authority Root Certificates igtf-policy-experimental - IGTF experimental Authority Root Certificates igtf-policy-mics - IGTF MICS profile for Authority Root Certificates igtf-policy-slcs - IGTF SLCS profile for Authority Root Certificates igtf-policy-unaccredited - IGTF unaccredited Authority Root Certificates To access further information about this package, please visit the following URL: http://mentors.debian.net/package/igtf-policy-bundle Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/i/igtf-policy-bundle/igtf-policy-bundle_1.52-1.dsc More information about hello can be obtained from http://www.example.com. Changes since the last upload: * New upstream version This package contains a collection of CAs that are not in the ca-certificates package, but which are regularly used in the context of grid computing. The IGTF bundles the forces of three policy management authorities, the EUGridPMA, the TAGPMA and APGridPMA. The packages are bundled according to the profiles defined by the IGTF. I've implemented integration with the ca-certificates packages and admins can choose to whitelist or blacklist certain CAs. Regards, Dennis van Dok -- D.H. van Dok :: Software Engineer :: www.nikhef.nl/grid :: Phone +31 20 592 22 28 :: http://www.nikhef.nl/~dennisvd/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702329: template text
I seem to consistently leave template text in these ITPs and RFSs I fill in... Please ignore the 'hello' part. For more information see http://www.igtf.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#684102: RFS: igtf-policy-bundle/1.46-1 [ITP] Profiles for Authority Root Certificates
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package igtf-policy-bundle * Package name: igtf-policy-bundle Version : 1.46-1 Upstream Author : David Groep i...@eugridpma.org * URL : http://www.igtf.net/ * License : Apache 2 Section : misc It builds those binary packages: igtf-policy-classic - IGTF classic profile for Authority Root Certificates igtf-policy-experimental - IGTF experimental Authority Root Certificates igtf-policy-mics - IGTF MICS profile for Authority Root Certificates igtf-policy-slcs - IGTF SLCS profile for Authority Root Certificates igtf-policy-unaccredited - IGTF unaccredited Authority Root Certificates To access further information about this package, please visit the following URL: http://mentors.debian.net/package/igtf-policy-bundle Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/i/igtf-policy-bundle/igtf-policy-bundle_1.46-1.dsc More information about The IGTF can be obtained from http://www.igtf.net/ Regards, Dennis van Dok -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664165: RFS: not-yet-commons-ssl/0.3.9-2 [ITP]
Op 04-08-12 07:45, Bart Martens schreef: Hi Dennis, The package at mentors is no longer there. What happened ? Are you still working on not-yet-commons-ssl, and do you still need a sponsor ? Hi Bart, I guess it was autoremoved after 20 weeks of not finding a sponsor. I've uploaded it again; I'm still looking for a sponsor. The packaging of not-yet-commons-ssl is part of a larger work to include a bunch of software that my team at Nikhef is developing as part of the European Grid Infrastructure middleware. Cheers, Dennis -- D.H. van Dok :: Software Engineer :: www.nikhef.nl :: www.biggrid.nl Phone +31 20 592 22 28 :: http://www.nikhef.nl/~dennisvd/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#674146: linux-image-3.2.0-24-generic: general protection fault: 0000 [#1] SMP on wakeup
Package: linux-image-3.2.0-24-generic Version: 3.2.0-24.38 Severity: normal Dear Maintainer, I opened my laptop which was in sleep mode at the time. Within a few moments, the console showed a kernel panic. I could still continue to unlock the screen, save my programs and reboot without further trouble. The file /var/log/kern.log recorded the data that was seen on the screen. May 22 18:12:57 camilla kernel: [141665.618150] general protection fault: [#1] SMP May 22 18:12:57 camilla kernel: [141665.618196] CPU 1 May 22 18:12:57 camilla kernel: [141665.618208] Modules linked in: nls_utf8 udf crc_itu_t xts gf128mul xfs nls_iso8859_1 nls_cp437 vfat fat uas usb_storage snd_hrtimer ip6table_filter ip6_tables ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ipt_REJECT xt_CHECKSUM iptable_mangle xt_tcpudp iptable_filter ip_tables x_tables bridge stp sit tunnel4 kvm_intel kvm rfcomm bnep parport_pc ppdev ib_iser rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi binfmt_misc dm_crypt snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event btusb bluetooth arc4 ath9k mac80211 snd_seq snd_timer snd_seq_device appletouch ath9k_common ath9k_hw ath snd soundcore joydev cfg80211 applesmc snd_page_alloc input_polldev apple_bl mac_hid lp parport hid_apple usbhid hid sky2 i915 drm_kms_helper drm i2c_algo_bit video May 22 18:12:57 camilla kernel: [141665.618946] May 22 18:12:57 camilla kernel: [141665.618956] Pid: 5393, comm: java Tainted: GW3.2.0-24-generic #38-Ubuntu Apple Inc. MacBook2,1/Mac-F4208CAA May 22 18:12:57 camilla kernel: [141665.619003] RIP: 0010:[8103dc49] [8103dc49] __ticket_spin_lock+0x9/0x30 May 22 18:12:57 camilla kernel: [141665.619046] RSP: 0018:8808fda8 EFLAGS: 00010086 May 22 18:12:57 camilla kernel: [141665.619069] RAX: 0001 RBX: 8808ff58 RCX: May 22 18:12:57 camilla kernel: [141665.619097] RDX: 8808ffd8 RSI: 88000a2896f0 RDI: beed60c78000 May 22 18:12:57 camilla kernel: [141665.619125] RBP: 8808fda8 R08: 8808e000 R09: May 22 18:12:57 camilla kernel: [141665.619151] R10: R11: 0001 R12: 0001 May 22 18:12:57 camilla kernel: [141665.619179] R13: 7f0dc6e70530 R14: ff92 R15: May 22 18:12:57 camilla kernel: [141665.619208] FS: 7f0dc6e71700() GS:8800bdf0() knlGS: May 22 18:12:57 camilla kernel: [141665.619240] CS: 0010 DS: ES: CR0: 80050033 May 22 18:12:57 camilla kernel: [141665.619263] CR2: 006db1b0 CR3: 65ded000 CR4: 06e0 May 22 18:12:57 camilla kernel: [141665.619292] DR0: DR1: DR2: May 22 18:12:57 camilla kernel: [141665.619320] DR3: DR6: 0ff0 DR7: 0400 May 22 18:12:57 camilla kernel: [141665.619348] Process java (pid: 5393, threadinfo 8808e000, task 88000a2896f0) May 22 18:12:57 camilla kernel: [141665.619378] Stack: May 22 18:12:57 camilla kernel: [141665.619390] 8808fdb8 8165ca85 8808fe58 8107ccce May 22 18:12:57 camilla kernel: [141665.619435] 88000a289b50 8808fee8 8808ff58 88000a2896f0 May 22 18:12:57 camilla kernel: [141665.619479] 8800b3ac 88000a289c58 88003ed99080 be100010 May 22 18:12:57 camilla kernel: [141665.619523] Call Trace: May 22 18:12:57 camilla kernel: [141665.619539] [8165ca85] _raw_spin_lock_irq+0x15/0x20 May 22 18:12:57 camilla kernel: [141665.619566] [8107ccce] get_signal_to_deliver+0xde/0x420 May 22 18:12:57 camilla kernel: [141665.619594] [81013865] do_signal+0x45/0x130 May 22 18:12:57 camilla kernel: [141665.619618] [8109ee51] ? futex_wake+0x1/0x130 May 22 18:12:57 camilla kernel: [141665.619641] [810a0a0c] ? do_futex+0x7c/0x1b0 May 22 18:12:57 camilla kernel: [141665.619664] [810a0c4a] ? sys_futex+0x10a/0x1a0 May 22 18:12:57 camilla kernel: [141665.619689] [81177da0] ? vfs_write+0x110/0x180 May 22 18:12:57 camilla kernel: [141665.619712] [81013b15] do_notify_resume+0x65/0x80 May 22 18:12:57 camilla kernel: [141665.619734] [81665050] int_signal+0x12/0x17 May 22 18:12:57 camilla kernel: [141665.619756] Code: 00 00 48 c7 c1 51 da 03 81 48 c7 c2 4e da 03 81 e9 dd fe ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 55 b8 00 00 01 00 48 89 e5 f0 0f c1 07 89 c2 c1 ea 10 66 39 c2 74 13 66 0f 1f 84 00 00 00 May 22 18:12:57 camilla kernel: [141665.620009] RIP [8103dc49] __ticket_spin_lock+0x9/0x30 May 22 18:12:57 camilla kernel: [141665.620009] RSP 8808fda8 May 22 18:12:57 camilla kernel: [141665.620009] ---[ end trace
Bug#674146: Acknowledgement (linux-image-3.2.0-24-generic: general protection fault: 0000 [#1] SMP on wakeup)
Sorry, this bug should have been directed to Ubuntu instead of Debian. I mixed the bug reporting tools. D. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670254: RFS: lcmaps/1.5.5-1 [ITP] -- I'm looking for a sponsor.
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package lcmaps * Package name: lcmaps Version : 1.5.5-1 Upstream Author : Nikhef Grid Security Middleware Team grid-mw-secur...@nikhef.nl * URL : https://wiki.nikhef.nl/grid/Site_Access_Control * License : Apache 2 Section : libs It builds those binary packages: lcmaps-basic-interface - LCMAPS header files for basic interfaces lcmaps-globus-interface - LCMAPS header files for Globus interfaces lcmaps-openssl-interface - LCMAPS header files for OpenSSL interfaces liblcmaps-dev - LCMAPS development libraries liblcmaps-without-gsi-dev - LCMAPS development libraries (Without GSI) liblcmaps-without-gsi0 - Grid mapping service without GSI liblcmaps0 - Grid (X.509) and VOMS credentials to local account mapping servic To access further information about this package, please visit the following URL: http://mentors.debian.net/package/lcmaps Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/l/lcmaps/lcmaps_1.5.5-1.dsc More information about hello can be obtained from http://www.example.com. Changes since the last upload: New upstream release. Fixes out-of-source build failure with --disable-gsi-mode. It now builds both with and without GSI mode libraries in one package. Regards, Dennis van Dok -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#669337: ITP: llrun -- Test run utility for LCAS and/or LCMAPS
Package: wnpp Severity: wishlist Owner: Dennis van Dok denni...@nikhef.nl * Package name: llrun Version : 0.1.3 Upstream Author : Nikhef Grid Security Middleware Team grid-mw-secur...@nikhef.nl * URL : https://wiki.nikhef.nl/grid/GLExec * License : Apache 2 Programming Lang: C Description : Test run utility for LCAS and/or LCMAPS The llrun tool is meant to debug or test LCAS and/or LCMAPS configuration files. It essentially does a full run, without any of the security settings and precautions used by e.g. gLExec. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#669275: ITP: mkgltempdir -- Utility to create a directory owned by the gLExec target user
Package: wnpp Severity: wishlist Owner: Dennis van Dok denni...@nikhef.nl * Package name: mkgltempdir Version : 0.0.3 Upstream Author : Nikhef Grid Security Middleware Team grid-mw-secur...@nikhef.nl * URL : http://wiki.nikhef.nl/grid/GLExec_TransientPilotJobs * License : Apache 2 Programming Lang: Bourne Shell Description : Utility to create a directory owned by the gLExec target user The gLExec program takes care of switching the user identity based on grid credentials. Some use cases, in particular multi-user pilot-job frameworks, may have a need to securely create a temporary directory owned by the target user. The mkgltempdir utility takes care of creating such a directory. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#669275: ITP: mkgltempdir -- Utility to create a directory owned by the gLExec target user
Op 18-04-12 20:10, Adam D. Barratt schreef: On Wed, 2012-04-18 at 19:26 +0200, Dennis van Dok wrote: * Package name: mkgltempdir Version : 0.0.3 Upstream Author : Nikhef Grid Security Middleware Team grid-mw-secur...@nikhef.nl * URL : http://wiki.nikhef.nl/grid/GLExec_TransientPilotJobs The link to the source code on that page is broken, fwiw. Thanks; that's fixed now. I suspect ftp-master are unlikely to approve a new package for a single 7kb shell script. Is there not an existing package where this could fit? I suppose it could be packaged along with glexec. Cheers, Dennis -- D.H. van Dok :: Software Engineer :: www.nikhef.nl :: www.biggrid.nl Phone +31 20 592 22 28 :: http://www.nikhef.nl/~dennisvd/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666229: Adding CA certficates outside of ca-certificates (see ITP #666229)
Hi Thijs, Op 17-04-12 09:26, Thijs Kinkhorst schreef: Hi Dennis, You're probably aware that there's already an APT-compatible repository that contains Debian packages for the current IGTF distribution? https://dist.eugridpma.info/distribution/igtf/current/ How does this package relate to that? What goal do you want to reach by uploading to Debian proper? Yes, I'm aware of the APT repository of the IGTF; the maintainer is a close colleague. The current packages are not made with the Debian Policy in mind. Although they're not outright awful, we've discussed how we could bring the IGTF distribution more in-line with the Debian way of packaging. For administrators it's always an extra hurdle to enable or install extra repositories. Having the IGTF distribution in Debian proper would remove this burden. In the IGTF community it's more or less expected that relying parties update their trust anchors not too long after new IGTF updates are released - if a relying party uses packages from Debian (old)stable they can easily be two or three years old and are not easily updated. I'm not sure if newly accredited CA's would be enthusiastic to wait that long, for example. Worse than that, CAs that lose their accreditation should be removed. Isn't it possible to have intermediate updates in stable in such cases? In the same way security updates are done? I'm unfortunately not at the upcoming EUgridPMA meeting in Karlsruhe this May, but perhaps there's another opportunity where we can meet to discuss the ideas and specifics. Yes, sure. My contact details are below. Thanks! Dennis -- D.H. van Dok :: Software Engineer :: www.nikhef.nl :: www.biggrid.nl Phone +31 20 592 22 28 :: http://www.nikhef.nl/~dennisvd/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666229: Adding CA certficates outside of ca-certificates (see ITP #666229)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I would like to include the CA distribution of the IGTF (www.igtf.net), which is an international collaboration of CAs for use in the e-science communities (i.e. scientific grid computing cloud computing). The certificates in this collection are typically used for service certificates (compute storage endpoints, authentication services, etc.) and user certificates. They are not commonly used for normal web servers. That is why I don't think they should be included in the ca-certificates package. There seems to be no real way to include extra ca-certificates-* packages at the moment. I've tried to conform as much as possible to the structure of the ca-certificates package, and the way I've packaged it right now is that the administrator has the choice to include individual certificates from IGTF in /etc/ssl upon reconfiguring ca-certficates. http://mentors.debian.net/package/igtf-policy-bundle The policy bundle offers a choice of opt-in or opt-out, so it's easy to enable 'all but a few' or 'none but a few' certificates. And enabling here means placing symlinks in /etc/grid-security/certificates, which is the de facto place for grid middleware to look for certificates. I welcome thoughts and comments on this work. Best, Dennis van Dok - -- D.H. van Dok :: Software Engineer :: www.nikhef.nl :: www.biggrid.nl Phone +31 20 592 22 28 :: http://www.nikhef.nl/~dennisvd/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+MIk4ACgkQIITq5lEwLHe5+gCeI2/DS4xpSkJxLmHpyR8VkQqX 2LkAn1veYyGNIdzx9QiLVvkQ0dCivRhK =JeQF -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666229: ITP: igtf-policy-bundle -- IGTF profiles for Authority Root Certificates
Op 31-03-12 04:47, Christoph Anton Mitterer wrote: On Sat, 2012-03-31 at 01:38 +0200, Dennis van Dok wrote: It's better not to get these things mixed up too much. Definitely. I agree that the actual PEM files should be placed in /usr/share/ca-certificates/ and I'd propose a structure like this: /usr/share/ca-certificates/igtf/classic /usr/share/ca-certificates/igtf/slcs /usr/share/ca-certificates/igtf/mlcs That's *almost* how I've packaged it. One thing I just recall: OpenSSL hash links... pre/post 1.0 format. I'm not sure what I prefer: a) ship/create symlinks for both formats b) ship/create symlinks for post 1.0 only I went with a) at the moment. That is what 'upstream' does and it's really handy for legacy software. But I guess this is a separate debconf thingy,... configuring what you put in /etc/grid-security and not the one from ca-certificates? yes /etc/grid-security should then _only_ contain symlinks, IMHO. Agreed, and that's how it works. Not sure if this is easily possible, but it would be nice, if the cert selection was somehow sorted by the respective PMA.. and perhaps when you see the country code of the respective CA. I'm not sure how I could easily implement this. I don't see this as such an urgent matter, and as I'm apolitical I don't understand what the fuss is about. Splitting the file hierarchy would make sense here, as people quickly recognise which type (i.e. MLCS/SLCS) a cert is of. This is indeed split into different packages. I revised my idea,.. ALL (that are installed) should show up... but one should be able to see where they're belonging to, which is easily possible via the path. Agreed. but there may even be some from the 'unaccredited' set that you would want to have in ca-certificates (e.g. the TERENA-SSL-CA). TERENA is in unaccredited,.. damn... Nevertheless, I think if you follow my idea to split the packages and make one metapackage, I would NOT depend on the -unaccredited package at most suggest it.. but even that is questionable, because while specifically TERENA is likely generally useful, for the main purpose of IGTF it's not. Rather than start a lot of fuss here...maybe TERENA could be included in the ca-certificates package. It takes only a couple of sponsors IIRC. For the ca-certifcates part... it's anyway up the the admin to decide (if he configured ask,... if he did not one can't help him ;) ) Well on the other hand... uhm... I'm just thinking what a meta package should do (if you split up) I haven't given the metapackage a thought yet. I also don't see the need as there are just three packages for all the accredited stuff. Better to make it a conscious choice. No I don't mean older versions... IGTF updates quite often... once the packages are in stable (e.g. wheezy) we still would need to update it... I guess stable-updates is what this is called in the meantime. Sure, if upstream brings out a new version, the Debian stable package would have to be updated. Isn't this essentially a security fix? When you're from NIKHEF you can probably easily get David's OpenPGP key in a secure way to add only securely downloaded igtf bundles to Debian :) Nothing NIKHEF specific here, I thought David Groep is from NIKHEF? And he signed the key that is used to sign the eugridpma distripution key... Well, sure. And I'll take his word that it's the right bundle ;-) He's practically in the next office. I can promise that I will diligently check the signatures, but then you'll have to trust me that I will do as I say... I'm all for a further discussion of how to do this properly for Debian; I've put a lot of my own thought into this and I've reflected this with others, notably the upstream maintainer, but I still consider this very much as an initial attempt. Well I guess you're on a good way... especially your idea to separate between ca-certificates an another debconf for grid-security = +1 Thanks, Dennis -- D.H. van Dok :: Software Engineer :: www.nikhef.nl :: www.biggrid.nl Phone +31 20 592 22 28 :: http://www.nikhef.nl/~dennisvd/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#668604: ITP: lcmaps-plugins-tracking-groupid -- Groupid tracking plugin for the LCMAPS authorization framework
Package: wnpp Severity: wishlist Owner: Dennis van Dok denni...@nikhef.nl * Package name: lcmaps-plugins-tracking-groupid Version : 0.1.0-1 Upstream Author : Nikhef Grid Middleware Security Team grid-mw-secur...@nikhef.nl * URL : http://software.nikhef.nl/security/lcmaps-plugins-tracking-groupid/ * License : Apache 2 Programming Lang: C Description : Groupid tracking plugin for the LCMAPS authorization framework The local Centre MAPping Service (LCMAPS) is a security middleware component that processes the users Grid credentials (typically X.509 proxy certificates and VOMS attributes) and maps the user to a local account based on the site local policy. This package contains the tracking group ID plug-in. This plug-in will add one or more secondary Group IDs to the final mapping result. Some batch systems can be configured to add a unique group ID to a batch job to be able to track its movements; this should be preserved even across user ID switches through LCMAPS. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#668525: ITP: scas -- Site central authorization service
Package: wnpp Severity: wishlist Owner: Dennis van Dok denni...@nikhef.nl * Package name: scas Version : 0.3.6 Upstream Author : Nikhef Grid Security Middleware Team grid-mw-secur...@nikhef.nl * URL : https://wiki.nikhef.nl/grid/Site_Access_Control * License : Apache 2 Programming Lang: C Description : Site central authorization service The Site Central Authorization Service (SCAS) will make authorization and mapping decision centrally. It uses HTTPS authentication to authenticate a client (as regular user or pilot job user) and present user credentials. The return message will contain a deny of permit decision, and when permitted Unix UID, primary GID and secondary GIDs will be returned. The primary client tool is gLExec, but the client is actually an LCMAPS plugin, so other tools like all the pre-WS GT4 gatekeepers, gridftpd and gsi-opensshd tools can also utilize this client server interaction. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#667705: ITP: lcas-plugins-voms -- VOMS plugins for the LCAS authorization framework
Package: wnpp Severity: wishlist Owner: Dennis van Dok denni...@nikhef.nl * Package name: lcas-plugins-voms Version : 1.3.10-1 Upstream Author : Nikhef Grid Security Middleware Team grid-mw-secur...@nikhef.nl * URL : http://wiki.nikhef.nl/grid/Site_Access_Control * License : Apache 2 Programming Lang: C Description : VOMS plugins for the LCAS authorization framework LCAS makes binary ('yes' or 'no') authorization decisions at the site and resource level, based on grid (X.509) credentials and VOMS attributes. It has a pluggable interface. This package contains the VOMS plug-ins. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#667071: ITP: lcmaps-plugins-basic -- Standard LCMAPS plug-ins for basic account mapping
Package: wnpp Severity: wishlist Owner: Dennis van Dok denni...@nikhef.nl * Package name: lcmaps-plugins-basic Version : 1.5.0-1 Upstream Author : Nikhef Grid Security Middleware Team grid-mw-secur...@nikhef.nl * URL : https://wiki.nikhef.nl/grid/Site_Access_Control * License : Apache 2 Programming Lang: C Description : Standard LCMAPS plug-ins for basic account mapping The Local Centre MAPping Service (LCMAPS) is a security middleware component that processes the users Grid (X.509) credentials and maps the user to a local account based on the site local policy. Almost all of the functionality is implemented by plug-ins. This package contains a set of basic plugins that will probably be required in most common cases. - dummy (good/bad), useful as final states in policy expressions - localaccount, for fixed mappings of specific users - poolaccount, for mapping known users to a generic pool - posixenf, for enforcing the mapping (making the actual switch) - basic-ldap, for interacting with an LDAP account database -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666905: ITP: xacml -- SAML 2.0 profile of XACML v2.0
Package: wnpp Severity: wishlist Owner: Dennis van Dok denni...@nikhef.nl * Package name: xacml Version : 1.1.1-1 Upstream Author : Nikhef Grid Security Middleware Team grid-mw-secur...@nikhef.nl * URL : http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml * License : Apache 2 Programming Lang: C Description : SAML 2.0 profile of XACML v2.0 This API provides a basic implementation of the SAML 2.0 profile of XACML v2.0, including support for obligations in XACML response messages. It aids in writing XACML clients and servers. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666910: ITP: lcmaps-plugins-scas-client -- SCAS client plugin for the LCMAPS authorization framework
Package: wnpp Severity: wishlist Owner: Dennis van Dok denni...@nikhef.nl * Package name: lcmaps-plugins-scas-client Version : 0.3.4-1 Upstream Author : Nikhef Grid Middleware Security Team grid-mw-secur...@nikhef.nl * URL : https://wiki.nikhef.nl/grid/Site_Access_Control * License : Apache 2 Programming Lang: C Description : SCAS client plugin for the LCMAPS authorization framework The Local Centre MAPping Service (LCMAPS) is a security middleware component that processes the users Grid credentials (typically X.509 proxy certificates and VOMS attributes) and maps the user to a local account based on the site local policy. This package contains the SCAS client plug-in, required to do authorization callouts to the SCAS server. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666229: ITP: igtf-policy-bundle -- IGTF profiles for Authority Root Certificates
Op 30-03-12 13:40, Christoph Anton Mitterer schreef: Hi Dennis. Hi Chris, Running the LMU-LRZ Tier-2 this is quite good news, however.. (H'm, coincidentally I'm just back from LRZ after the EGI community forum.) On Thu, 2012-03-29 at 23:29 +0200, Dennis van Dok wrote: The certificates are kept in /usr/share/igtf-policy/ and /usr/share/ca-certificates/igtf-*/. Why two locations (i.e. why the one outside of /usr/share/ca-certificates/) There is an easy answer and a more complicated answer. The easy answer is that the IGTF CAs come with several files besides just the certificates. The info, namespaces, crl_url and signing_policy files are used by tools such as fetch-crl. And each certificate is also available as hash.0. They would pollute the certificate collection if they were installed under /usr/share/ca-certificates. I now just put the certificates there for convenience; dpkg-reconfigure ca-certificates will pick them up, and they can be enabled for general-purpos uses. The more complicated answer is that the IGTF collection has a different purpose than the general ca_certificates. It covers different use cases, has different security controls (the IGTF works with CRLs) and covers different risks. It's better not to get these things mixed up too much. The fact that the same technology is involved is not enough of a reason to place them together. They are meant to be placed in /etc/grid-security/certificates, where the commonly used grid middleware will look for it; it is also possible to include (some of) the certificates in /etc/ssl/certs by using dpkg-reconfigure ca-certificates. Well here the problems start, IMHO. I always considered the whole /etc/grid-security/ quite broken and not more than a quite and dirty hack to ease up life with multiple grid apps. Nevertheless, this is a location used by many, many systems. It more or less contradicts the way certificates are meant to be handled in Debian (i.e. ca-certificates). Are you going to automatically create /etc/grid-security/certificates and put links in there? Yes; right now the package works (you can try already as it is in mentors[1]) by symlinking the files in /etc/grid-security/certificates. 1. http://mentors.debian.net/package/igtf-policy-bundle Will it be possible to configure only selected CAs? Yes, through debconf. It's either exclusion based (install all but a selected few) or inclusion based (only install a selected few). Will you integrated into ca-certificates (i.e. which certs-get enabled and not)? There is some integration; running dpkg-reconfigure on ca-certificates after installing an igtf package with ca-certificates/trust_new_crts: ask will give you the option to select the IGTF certificates. This choice is independent of what's installed in /etc/grid-security/certificates (again, different use cases!) Probably not all certificates in IGTF should show up in what ca-certificates creates (i.e. SLCS and MLCS). Probably not; but there may even be some from the 'unaccredited' set that you would want to have in ca-certificates (e.g. the TERENA-SSL-CA). We could make a hand-picked selection but a) who would do the choosing and b) what would be the criteria? Neither a or b are very clear to me. At least in the current setup it's clear that the choice and the responsibility fall to the sysadmin. btw: Are you going to provide backports or better said volatile support? ...Not sure what this means but I could provide backports to older flavours of Debian, Ubuntu, if there is enough demand. When you're from NIKHEF you can probably easily get David's OpenPGP key in a secure way to add only securely downloaded igtf bundles to Debian :) Nothing NIKHEF specific here, you'd have to have a face-to-face at some point and he gets around quite a lot... Not sure what you mean by 'securely downloaded'. Do you mean over an SSL connection, or do you mean that it's verified that the downloaded sources are the same as the original? I'm all for a further discussion of how to do this properly for Debian; I've put a lot of my own thought into this and I've reflected this with others, notably the upstream maintainer, but I still consider this very much as an initial attempt. Cheers, Dennis -- D.H. van Dok :: Software Engineer :: www.nikhef.nl :: www.biggrid.nl Phone +31 20 592 22 28 :: http://www.nikhef.nl/~dennisvd/ smime.p7s Description: S/MIME cryptografische ondertekening
Bug#666229: ITP: igtf-policy-bundle -- IGTF profiles for Authority Root Certificates
Package: wnpp Severity: wishlist Owner: Dennis van Dok denni...@nikhef.nl * Package name: igtf-policy-bundle Version : 1.46 Upstream Author : David Groep i...@eugridpma.org * URL : http://www.igtf.net/ * License : Apache 2 Programming Lang: X.509 CA certificates Description : IGTF profiles for Authority Root Certificates The International Grid Trust Federation (IGTF) maintains a common trust base for the benefit of distributed science and research computing infrastructures by maintaining a list of trust anchors, for accredited authorities. The distribution contains root certificates, certificate revocation list (CRL) locations, contact information, and signing policies. The package is split up according to the different profiles of the IGTF (each profile covers a different set of rules and policies). The most important ones are classic, mics (member integrated credential service) and slcs (short lived credential service). The trust anchors maintained by the IGTF form a trust backbone for many large-scale science communities, among which the European Grid Infrastructure (http://www.ige.eu/) and the World-wide LHC Computing Grid (http://lcg.web.cern.ch/lcg/). The certificates are kept in /usr/share/igtf-policy/ and /usr/share/ca-certificates/igtf-*/. They are meant to be placed in /etc/grid-security/certificates, where the commonly used grid middleware will look for it; it is also possible to include (some of) the certificates in /etc/ssl/certs by using dpkg-reconfigure ca-certificates. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664738: ITP: glexec -- User identity switching tool based on grid credentials
Package: wnpp Severity: wishlist Owner: Dennis van Dok denni...@nikhef.nl * Package name: glexec Version : 0.9.4 Upstream Author : Mischa Sallé msa...@nikhef.nl * URL : https://wiki.nikhef.nl/grid/GLExec * License : Apache 2 Programming Lang: C Description : User identity switching tool based on grid credentials gLExec is a program that acts as a light-weight 'gatekeeper'. it takes Grid credentials as input, and takes the local site policy into account to authenticate and authorize the credentials. It will then switch to a new execution sandbox and execute the given command as the switched identity. gLExec is also capable of functioning as a light-weight control point which offers a binary yes/no result in logging-only mode. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664689: ITP: argus-pep-api-c -- Argus PEP client library
Package: wnpp Severity: wishlist Owner: Dennis van Dok denni...@nikhef.nl * Package name: argus-pep-api-c Version : 2.0.3 Upstream Author : Valery Tschopp valery.tsch...@switch.ch * URL : https://twiki.cern.ch/twiki/bin/view/EGEE/AuthorizationFramework * License : Apache 2 Programming Lang: C Description : Argus PEP client library The Argus PEP client API for C is a multithread-safe client library used to communicate with the Argus PEP Server. It authorizes request and receives authorization response back from Argus. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664699: ITP: lcmaps-plugins-c-pep -- C-PEP plugin for the LCMAPS authorization framework
Package: wnpp Severity: wishlist Owner: Dennis van Dok denni...@nikhef.nl * Package name: lcmaps-plugins-c-pep Version : 1.2.1 Upstream Author : The Nikhef Grid Security Middleware Team grid-mw-secur...@nikhef.nl * URL : https://wiki.nikhef.nl/grid/Site_Access_Control * License : Apache 2 Programming Lang: C Description : C-PEP plugin for the LCMAPS authorization framework The Local Centre MAPping Service (LCMAPS) is a security middleware component that processes the users Grid credentials (typically X.509 proxy certificates and VOMS attributes) and maps the user to a local account based on the site local policy. This package contains the PEP client plug-in. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664181: RFS: trustmanager/3.0.5-1 [ITP]
Package: sponsorship-requests Severity: wishlist Package: sponsorship-requests Severity: normal [important for RC bugs, wishlist for new packages] Dear mentors, I am looking for a sponsor for my package trustmanager * Package name: trustmanager Version : 3.0.5-1 Upstream Author : [fill in name and email of upstream] * URL : [fill in URL of upstreams web site] * License : [fill in] Section : java It builds those binary packages: libtrustmanager-java - Java TrustManager interface with grid features libtrustmanager-java-doc - Java TrustManager interface with grid features To access further information about this package, please visit the following URL: http://mentors.debian.net/package/trustmanager Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/t/trustmanager/trustmanager_3.0.5-1.dsc More information about hello can be obtained from http://www.example.com. Changes since the last upload: * Initial release. (Closes: #656389) Regards, Dennis van Dok -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664181: Info received (RFS: trustmanager/3.0.5-1 [ITP])
Sorry for not filling the template properly. Here's the details: * Package name: trustmanager Version : 3.0.5-1 Upstream Author : Joni Hahkala joni.hahk...@cern.ch * URL : https://twiki.cern.ch/twiki/bin/view/EGEE/TrustManager * License : Apache 2 Section : java Dennis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664165: RFS: not-yet-commons-ssl/0.3.9-2 [ITP]
Op 16-03-12 00:26, I wrote: More information about hello can be obtained from http://www.example.com. I overlooked this snippet from the RFS template. You won't find much information there :-). The obvious place to look is of course: http://juliusdavies.ca/commons-ssl/ Cheers, Dennis van Dok -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664165: RFS: not-yet-commons-ssl/0.3.9-2 [ITP]
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package not-yet-commons-ssl * Package name: not-yet-commons-ssl Version : 0.3.9-2 Upstream Author : Julius Davies juliusdav...@gmail.com * URL : http://juliusdavies.ca/commons-ssl/ * License : Apache 2 Section : java It builds those binary packages: libnot-yet-commons-ssl-java - Not-yet-commons-SSL is a library to make SSL and Java easier To access further information about this package, please visit the following URL: http://mentors.debian.net/package/not-yet-commons-ssl Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/n/not-yet-commons-ssl/not-yet-commons-ssl_0.3.9-2.dsc More information about hello can be obtained from http://www.example.com. Changes since the last upload: * extended copyright details after contacting upstream author * removed duplicate cdbs build dependency * updated copyright header * updated to Debian policy 3.9.3 * added version control reference fields Regards, Dennis van Dok -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#663212: ITP: lcas-lcmaps-gt4-interface -- Mapping interface between Globus Toolkit and LCAS/LCMAPS
Package: wnpp Severity: wishlist Owner: Dennis van Dok denni...@nikhef.nl * Package name: lcas-lcmaps-gt4-interface Version : 0.2.4 Upstream Author : Grid Middleware Security Team grid-mw-secur...@nikhef.nl * URL : https://wiki.nikhef.nl/grid/Site_Access_Control * License : Apache 2.0 Programming Lang: C Description : Mapping interface between Globus Toolkit and LCAS/LCMAPS This interface extends the basic map-file based mapping capabilities of the Globus Toolkit to use the full LCAS/LCMAPS pluggable framework, which includes pool accounts and VOMS attribute based decisions and mappings. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#662949: ITP: ees -- Execution Environment Service for the ARGUS framework
Package: wnpp Severity: wishlist Owner: Dennis van Dok denni...@nikhef.nl * Package name: ees Version : 0.1.2 Upstream Author : MW security developers at Nikhef grid-mw-secur...@nikhef.nl * URL : https://twiki.cern.ch/twiki/bin/view/EGEE/AuthorizationFramework * License : Apache 2 Programming Lang: C Description : Execution Environment Service for the ARGUS framework The EES is a service that can procure execution environments on Grid sites. These execution environments can be as simple as an existing Unix user account to which the supplied user credentials are mapped or as complex as deploying full virtual machines for a user. The role of the EES is to ensure that an appropriate site-specific execution environment is procured based on the site-agnostic obligations and attributes it receives as input in the form of SAML2-XACML2 requests. It responds to requests from the Policy Decision Point (PDP), but can also act as a standalone service. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#661615: ITP: lcas -- Authorization service for grid credentials
Package: wnpp Severity: wishlist Owner: Dennis van Dok denni...@nikhef.nl * Package name: lcas Version : 1.3.17 Upstream Author : Nikhef Grid MW Security grid-mw-secur...@nikhef.nl * URL : http://www.nikhef.nl/pub/projects/grid/gridwiki/index.php/Site_Access_Control * License : Apache-2.0 Programming Lang: C Description : Authorization service for grid credentials LCAS makes binary ('yes' or 'no') authorization decisions at the site and resource level. In making this decision, it can use a variety of inputs: the 'grid' name of the user (the Subject Distinguished Name), any VO attributes the user has (like VOMS FQANs), the name of the executable the user intends to execute. It supports basic black and white list functionality, but also more complex VOMS-based expressions, based on the GACL language. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#661617: ITP: lcas-plugins-basic -- Basic plugins for the LCAS authorization framework
Package: wnpp Severity: wishlist Owner: Dennis van Dok denni...@nikhef.nl * Package name: lcas-plugins-basic Version : 1.3.6 Upstream Author : The Nikhef Grid Security Middleware Team grid-mw-secur...@nikhef.nl * URL : http://www.nikhef.nl/pub/projects/grid/gridwiki/index.php/Site_Access_Control * License : Apache-2.0 Programming Lang: C Description : Basic plugins for the LCAS authorization framework LCAS makes binary ('yes' or 'no') authorization decisions at the site and resource level, based on grid (X.509) credentials and VOMS attributes. It has a pluggable interface. This package contains the basic plug-ins. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657151: ITP: argus-parent -- Argus parent module for Maven
Package: wnpp Severity: wishlist Owner: Dennis van Dok denni...@nikhef.nl * Package name: argus-parent Version : 1.5.1 Upstream Author : Valery Tschopp valery.tsch...@switch.ch * URL : https://twiki.cern.ch/twiki/bin/view/EGEE/AuthorizationFramework * License : Apache 2.0 Programming Lang: Java Description : Argus parent module for Maven Argus is a modular XACML based authorization service. It consists of several java components, such as policy decision points and policy enforcement points. The build system used is maven, and this package contains the common parent POM for these components. This package is only required as a build dependency when building the other Argus components. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656453: ITP: not-yet-commons-ssl -- Not-yet-commons-SSL is a library to make SSL and Java easier
Package: wnpp Severity: wishlist Owner: Dennis van Dok (Software Engineer) denni...@nikhef.nl * Package name: not-yet-commons-ssl Version : 0.3.9 Upstream Author : Julius Davies juliusdav...@gmail.com * URL : http://juliusdavies.ca/commons-ssl/ * License : Apache 2 Programming Lang: Java Description : Not-yet-commons-SSL is a library to make SSL and Java easier This library implements SSL functionality in a way that is easy and flexible. It improves security by checking CRLs by default. It allows options to be set or unset for each SSLSocketFactory. It supports many different formats of PKCS8 and OpenSSL Encrypted Private Keys, and it automatically detects the type of KeyMaterial or TrustMaterial. . It's called Not-Yet-Commons-SSL because of the intention of one day making it an official Apache project. It currently has no affiliation with the Apache Software Foundation. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656472: ITP: xmltooling -- low-level library to work with XML objects as regular Java beans
Package: wnpp Severity: wishlist Owner: Dennis van Dok (Software Engineer) denni...@nikhef.nl * Package name: xmltooling Version : 1.2.2 Upstream Author : Steven Carmody, Brown University * URL : https://wiki.shibboleth.net/confluence/display/OpenSAML/Home * License : Apache 2 Programming Lang: Java Description : low-level library to work with XML objects as regular Java beans The XMLTooling library provides the ability to work with XML as regular Java beans similar to the Java Architecture for XML Binding (JAXB), XMLBeans and XStream libraries. It offers fine control over (un)marshalling, extensibility and support for XML Digital Signatures and Encryption. In addition it provides a significant amount of support for more complex tasks such as signing and encryption, key resolution, key trust fabrics, and others. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656538: ITP: openws-java -- Java toolset to work with web services at a low level
Package: wnpp Severity: wishlist Owner: Dennis van Dok denni...@nikhef.nl * Package name: openws-java Version : 1.3.1 Upstream Author : Steven Carmody, Brown University * URL : https://wiki.shibboleth.net/confluence/display/OpenSAML/Home * License : Apache 2 Programming Lang: Java Description : Java toolset to work with web services at a low level The OpenWS library provides a growing set of tools to work with web services at a low level. These tools include classes for creating and reading SOAP messages, transport-independent clients for connecting to web services, and various transports for use with those clients. This is part of the OpenSAML library. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656541: ITP: opensaml-java -- API to work with SAML messages as Java bean objects
Package: wnpp Severity: wishlist Owner: Dennis van Dok denni...@nikhef.nl * Package name: opensaml-java Version : 2.3.2 Upstream Author : Steven Carmody, Brown University * URL : https://wiki.shibboleth.net/confluence/display/OpenSAML/Home * License : Apache 2 Programming Lang: Java Description : API to work with SAML messages as Java bean objects The OpenSAML library allows developers to work with SAML (Security Assertion Markup Language) messages as Java bean objects. This library supports the SAML 1.0, 1.1, and 2.0 specification. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656472: ITP: xmltooling -- low-level library to work with XML objects as regular Java beans
Op 19-01-12 18:17, Russ Allbery schreef: Dennis van Dok (Software Engineer) denni...@nikhef.nl writes: * Package name: xmltooling Version : 1.2.2 Upstream Author : Steven Carmody, Brown University * URL : https://wiki.shibboleth.net/confluence/display/OpenSAML/Home * License : Apache 2 Programming Lang: Java Description : low-level library to work with XML objects as regular Java beans The XMLTooling library provides the ability to work with XML as regular Java beans similar to the Java Architecture for XML Binding (JAXB), XMLBeans and XStream libraries. It offers fine control over (un)marshalling, extensibility and support for XML Digital Signatures and Encryption. The C++ version of this library was already packaged using the xmltooling source package name to support the Shibboleth SP, so unfortunately you'll have to use a different source package name. Maybe xmltooling-java? That is a good suggestion; I will file a new ITP. I don't understand why I didn't see this myself. I guess reportbug should also have caught it, but it complained about not being able to reach the BTS. Cheers, Dennis -- D.H. van Dok :: Software Engineer :: www.nikhef.nl :: www.biggrid.nl Phone +31 20 592 22 28 :: http://www.nikhef.nl/~dennisvd/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656542: ITP: argus-pep-common -- Argus PEP client and server common Java library
Package: wnpp Severity: wishlist Owner: Dennis van Dok denni...@nikhef.nl * Package name: argus-pep-common Version : 2.2 Upstream Author : Valery Tschopp valery.tsch...@switch.ch * URL : https://twiki.cern.ch/twiki/bin/view/EGEE/AuthorizationFramework * License : Apache 2 Programming Lang: Java Description : Argus PEP client and server common Java library ARGUS is a modular XACML based authorization service. The PEP (Policy Enforcement Point) is the client to the authorization service. This package contains common functionality to implement a PEP. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org