Bug#1051024: bookworm-pu: package igtf-policy-bundle/1.22-1~deb12u1

[Dennis van Dok]

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

[Dennis van Dok]

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

[Dennis van Dok]

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)

[Dennis van Dok]

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

[Dennis van Dok]

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

[Dennis van Dok]

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

[Dennis van Dok]

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

[Dennis van Dok]

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

[Dennis van Dok]

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

[Dennis van Dok]

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

[Dennis van Dok]

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

[Dennis van Dok]

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

[Dennis van Dok]

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

[Dennis van Dok]

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

[Dennis van Dok]

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

[Dennis van Dok]

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/

[Dennis van Dok]

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:

[Dennis van Dok]

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

[Dennis van Dok]

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

[Dennis van Dok]

> 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

[Dennis van Dok]

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

[Dennis van Dok]

Thanks for the update!

Cheers,

Dennis

Bug#869795: network-manager-openvpn-gnome: can't specify route without gateway or use vpn_gateway

[Dennis van Dok]

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

[Dennis van Dok]

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

[Dennis van Dok]

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

[Dennis van Dok]

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

[Dennis van Dok]

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

[Dennis van Dok]

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

[Dennis van Dok]

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

[Dennis van Dok]

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

[Dennis van Dok]

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 Siewior   Sun, 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

[Dennis van Dok]

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

[Dennis van Dok]

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

[Dennis van Dok]

On Wed, 14 Oct 2015 16:35:17 +0200 Adi Kriegisch  wrote:
> 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)

[Dennis van Dok]

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/

[Dennis van Dok]

-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/

[Dennis van Dok]

-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/

[Dennis van Dok]

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

[Dennis van Dok]

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

[Dennis van Dok]

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

[Dennis van Dok]

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

[Dennis van Dok]

-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}

[Dennis van Dok]

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}

[Dennis van Dok]

-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}

[Dennis van Dok]

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

[Dennis van Dok]

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

[Dennis van Dok]

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

[Dennis van Dok]

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

[Dennis van Dok]

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

[Dennis van Dok]

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

[Dennis van Dok]

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

[Dennis van Dok]

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

[Dennis van Dok]

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

[Dennis van Dok]

  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

[Dennis van Dok]

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

[Dennis van Dok]

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

[Dennis van Dok]

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

[Dennis van Dok]

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

[Dennis van Dok]

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

[Dennis van Dok]

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

[Dennis van Dok]

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

[Dennis van Dok]

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]

[Dennis van Dok]

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

[Dennis van Dok]

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)

[Dennis van Dok]

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.

[Dennis van Dok]

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

[Dennis van Dok]

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

[Dennis van Dok]

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

[Dennis van Dok]

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)

[Dennis van Dok]

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)

[Dennis van Dok]

-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

[Dennis van Dok]

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

[Dennis van Dok]

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

[Dennis van Dok]

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

[Dennis van Dok]

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

[Dennis van Dok]

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

[Dennis van Dok]

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

[Dennis van Dok]

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

[Dennis van Dok]

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

[Dennis van Dok]

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

[Dennis van Dok]

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

[Dennis van Dok]

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

[Dennis van Dok]

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]

[Dennis van Dok]

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])

[Dennis van Dok]

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]

[Dennis van Dok]

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]

[Dennis van Dok]

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

[Dennis van Dok]

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

[Dennis van Dok]

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

[Dennis van Dok]

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

[Dennis van Dok]

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

[Dennis van Dok]

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

[Dennis van Dok (Software Engineer)]

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

[Dennis van Dok (Software Engineer)]

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

[Dennis van Dok (Software Engineer)]

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

[Dennis van Dok]

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

[Dennis van Dok]

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

[Dennis van Dok]

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

Bug#656544: ITP: argus-pdp-pep-common -- Argus PDP and PEP server common library

[Dennis van Dok]

Package: wnpp
Severity: wishlist
Owner: Dennis van Dok denni...@nikhef.nl


* Package name: argus-pdp-pep-common
  Version : 1.3
  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 PDP and PEP server common library

 ARGUS is a modular XACML based authorization service. It consists of several
 components, such as policy decision points and policy enforcement points.
 This library contains a collection of common functionality found in the PDP
 and PEP server.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#656547: ITP: ees-pepd-oh -- EES ObligationHandler for Argus PEP Server

[Dennis van Dok]

Package: wnpp
Severity: wishlist
Owner: Dennis van Dok denni...@nikhef.nl


* Package name: ees-pepd-oh
  Version : 0.1.0
  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: Java
  Description : EES ObligationHandler for Argus PEP Server

 Argus is a modular XACML based authorization service. The Execution
 Environment Service (EES) is the component responsible for setting up
 the run-time environment for the authenticated user. The Policy
 Enforcement Point (PEP) may have issued a number of obligations that the
 EES must fulfil; this component takes care of that task.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org