Bug#666229: updated to 1.55

2013-12-05 Thread 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-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52a04497.1080...@nikhef.nl



Bug#710378: RFP: libevhtp -- libevent based HTTP API

2013-05-30 Thread Dennis van Dok
Package: wnpp
Severity: wishlist

* Package name: libevhtp
  Version : 1.2.0
  Upstream Author : Mark Ellzey 
* 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-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130530105944.19818.63111.reportbug@rowlf



Bug#669337: ITP: llrun -- Test run utility for LCAS and/or LCMAPS

2012-04-19 Thread Dennis van Dok
Package: wnpp
Severity: wishlist
Owner: Dennis van Dok 

* Package name: llrun
  Version : 0.1.3
  Upstream Author : Nikhef Grid Security Middleware Team 

* 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-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120419072223.22786.70965.reportbug@localhost6.localdomain6



Bug#669275: ITP: mkgltempdir -- Utility to create a directory owned by the gLExec target user

2012-04-18 Thread 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 
>> 
>> * 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-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f8f309f.4000...@nikhef.nl



Bug#669275: ITP: mkgltempdir -- Utility to create a directory owned by the gLExec target user

2012-04-18 Thread Dennis van Dok
Package: wnpp
Severity: wishlist
Owner: Dennis van Dok 

* Package name: mkgltempdir
  Version : 0.0.3
  Upstream Author : Nikhef Grid Security Middleware Team 

* 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-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120418172601.14217.27598.reportbug@localhost6.localdomain6



Bug#666229: Adding CA certficates outside of ca-certificates (see ITP #666229)

2012-04-17 Thread 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-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f8d247f.2010...@nikhef.nl



Bug#666229: ITP: igtf-policy-bundle -- IGTF profiles for Authority Root Certificates

2012-04-16 Thread 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-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f8c27e1.7080...@nikhef.nl



Bug#666229: Adding CA certficates outside of ca-certificates (see ITP #666229)

2012-04-16 Thread 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-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f8c2253.7070...@nikhef.nl



Bug#668604: ITP: lcmaps-plugins-tracking-groupid -- Groupid tracking plugin for the LCMAPS authorization framework

2012-04-13 Thread Dennis van Dok
Package: wnpp
Severity: wishlist
Owner: Dennis van Dok 

* Package name: lcmaps-plugins-tracking-groupid
  Version : 0.1.0-1
  Upstream Author : Nikhef Grid Middleware Security Team 

* 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-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120413121048.24253.23651.reportbug@localhost6.localdomain6



Bug#668525: ITP: scas -- Site central authorization service

2012-04-12 Thread Dennis van Dok
Package: wnpp
Severity: wishlist
Owner: Dennis van Dok 

* Package name: scas
  Version : 0.3.6
  Upstream Author : Nikhef Grid Security Middleware Team 

* 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-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120412132745.3617.70696.reportbug@localhost6.localdomain6



Bug#667705: ITP: lcas-plugins-voms -- VOMS plugins for the LCAS authorization framework

2012-04-05 Thread Dennis van Dok
Package: wnpp
Severity: wishlist
Owner: Dennis van Dok 

* Package name: lcas-plugins-voms
  Version : 1.3.10-1
  Upstream Author : Nikhef Grid Security Middleware Team 

* 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-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120406000743.3818.82677.reportbug@localhost6.localdomain6



Bug#667071: ITP: lcmaps-plugins-basic -- Standard LCMAPS plug-ins for basic account mapping

2012-04-03 Thread Dennis van Dok
Package: wnpp
Severity: wishlist
Owner: Dennis van Dok 

* Package name: lcmaps-plugins-basic
  Version : 1.5.0-1
  Upstream Author : Nikhef Grid Security Middleware Team 

* 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-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120403205331.16113.40382.reportbug@localhost6.localdomain6



Bug#666910: ITP: lcmaps-plugins-scas-client -- SCAS client plugin for the LCMAPS authorization framework

2012-04-02 Thread Dennis van Dok
Package: wnpp
Severity: wishlist
Owner: Dennis van Dok 

* Package name: lcmaps-plugins-scas-client
  Version : 0.3.4-1
  Upstream Author : Nikhef Grid Middleware Security Team 

* 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-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120402122035.10329.78947.reportbug@localhost6.localdomain6



Bug#666905: ITP: xacml -- SAML 2.0 profile of XACML v2.0

2012-04-02 Thread Dennis van Dok
Package: wnpp
Severity: wishlist
Owner: Dennis van Dok 

* Package name: xacml
  Version : 1.1.1-1
  Upstream Author : Nikhef Grid Security Middleware Team 

* 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-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120402115926.8656.99437.reportbug@localhost6.localdomain6



Bug#666229: ITP: igtf-policy-bundle -- IGTF profiles for Authority Root Certificates

2012-03-30 Thread 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 .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

2012-03-29 Thread Dennis van Dok
Package: wnpp
Severity: wishlist
Owner: Dennis van Dok 

* Package name: igtf-policy-bundle
  Version : 1.46
  Upstream Author : David Groep 
* 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-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120329212923.1102.40995.reportbug@localhost6.localdomain6



Bug#664738: ITP: glexec -- User identity switching tool based on grid credentials

2012-03-20 Thread Dennis van Dok
Package: wnpp
Severity: wishlist
Owner: Dennis van Dok 


* Package name: glexec
  Version : 0.9.4
  Upstream Author : Mischa Sallé 
* 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-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120320122551.3162.79034.reportbug@localhost6.localdomain6



Bug#664699: ITP: lcmaps-plugins-c-pep -- C-PEP plugin for the LCMAPS authorization framework

2012-03-19 Thread Dennis van Dok
Package: wnpp
Severity: wishlist
Owner: Dennis van Dok 


* Package name: lcmaps-plugins-c-pep
  Version : 1.2.1
  Upstream Author : The Nikhef Grid Security Middleware Team 

* 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-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120319231838.28320.45959.reportbug@localhost6.localdomain6



Bug#664689: ITP: argus-pep-api-c -- Argus PEP client library

2012-03-19 Thread Dennis van Dok
Package: wnpp
Severity: wishlist
Owner: Dennis van Dok 


* Package name: argus-pep-api-c
  Version : 2.0.3
  Upstream Author : Valery Tschopp 
* 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-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120319215237.19713.36702.reportbug@localhost6.localdomain6



Bug#663212: ITP: lcas-lcmaps-gt4-interface -- Mapping interface between Globus Toolkit and LCAS/LCMAPS

2012-03-09 Thread Dennis van Dok
Package: wnpp
Severity: wishlist
Owner: Dennis van Dok 


* Package name: lcas-lcmaps-gt4-interface
  Version : 0.2.4
  Upstream Author : Grid Middleware Security Team 
* 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-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120309132616.2096.6379.reportbug@localhost6.localdomain6



Bug#662949: ITP: ees -- Execution Environment Service for the ARGUS framework

2012-03-07 Thread Dennis van Dok
Package: wnpp
Severity: wishlist
Owner: Dennis van Dok 


* Package name: ees
  Version : 0.1.2
  Upstream Author : MW security developers at Nikhef 

* 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-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120307135702.13862.15413.reportbug@localhost6.localdomain6



Bug#661617: ITP: lcas-plugins-basic -- Basic plugins for the LCAS authorization framework

2012-02-28 Thread Dennis van Dok
Package: wnpp
Severity: wishlist
Owner: Dennis van Dok 


* Package name: lcas-plugins-basic
  Version : 1.3.6
  Upstream Author : The Nikhef Grid Security Middleware Team 

* 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-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120228143852.24795.62687.reportbug@localhost6.localdomain6



Bug#661615: ITP: lcas -- Authorization service for grid credentials

2012-02-28 Thread Dennis van Dok
Package: wnpp
Severity: wishlist
Owner: Dennis van Dok 


* Package name: lcas
  Version : 1.3.17
  Upstream Author : Nikhef Grid MW Security 
* 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-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120228143220.24639.40250.reportbug@localhost6.localdomain6



Bug#657151: ITP: argus-parent -- Argus parent module for Maven

2012-01-24 Thread Dennis van Dok
Package: wnpp
Severity: wishlist
Owner: Dennis van Dok 


* Package name: argus-parent
  Version : 1.5.1
  Upstream Author : Valery Tschopp 
* 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-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120124133350.26864.82186.reportbug@localhost6.localdomain6



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

2012-01-19 Thread Dennis van Dok
Package: wnpp
Severity: wishlist
Owner: Dennis van Dok 


* Package name: ees-pepd-oh
  Version : 0.1.0
  Upstream Author : MW security developers at Nikhef 

* 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-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120120013353.29607.67816.reportbug@localhost6.localdomain6



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

2012-01-19 Thread Dennis van Dok
Package: wnpp
Severity: wishlist
Owner: Dennis van Dok 


* Package name: argus-pdp-pep-common
  Version : 1.3
  Upstream Author : Valery Tschopp 
* 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-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120120011136.27944.7963.reportbug@localhost6.localdomain6



Bug#656542: ITP: argus-pep-common -- Argus PEP client and server common Java library

2012-01-19 Thread Dennis van Dok
Package: wnpp
Severity: wishlist
Owner: Dennis van Dok 


* Package name: argus-pep-common
  Version : 2.2
  Upstream Author : Valery Tschopp 
* 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-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120120010519.32077.53525.reportbug@localhost6.localdomain6



Bug#656472: ITP: xmltooling -- low-level library to work with XML objects as regular Java beans

2012-01-19 Thread Dennis van Dok
Op 19-01-12 18:17, Russ Allbery schreef:
> "Dennis van Dok (Software Engineer)"  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-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f188a1e.9090...@nikhef.nl



Bug#656541: ITP: opensaml-java -- API to work with SAML messages as Java bean objects

2012-01-19 Thread Dennis van Dok
Package: wnpp
Severity: wishlist
Owner: Dennis van Dok 


* 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-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120120005000.31961.73518.reportbug@localhost6.localdomain6



Bug#656538: ITP: openws-java -- Java toolset to work with web services at a low level

2012-01-19 Thread Dennis van Dok (Software Engineer)
Package: wnpp
Severity: wishlist
Owner: Dennis van Dok 


* 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-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120120003037.31701.38581.reportbug@localhost6.localdomain6



Bug#656472: ITP: xmltooling -- low-level library to work with XML objects as regular Java beans

2012-01-19 Thread Dennis van Dok (Software Engineer)
Package: wnpp
Severity: wishlist
Owner: "Dennis van Dok (Software Engineer)" 


* 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-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120119153448.30251.79213.reportbug@localhost6.localdomain6



Bug#656453: ITP: not-yet-commons-ssl -- Not-yet-commons-SSL is a library to make SSL and Java easier

2012-01-19 Thread Dennis van Dok (Software Engineer)
Package: wnpp
Severity: wishlist
Owner: "Dennis van Dok (Software Engineer)" 



* Package name: not-yet-commons-ssl
  Version : 0.3.9
  Upstream Author : Julius Davies 
* 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-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120119133830.14645.87569.reportbug@localhost6.localdomain6



Bug#656389: ITP: trustmanager -- Java TrustManager interface with grid features

2012-01-18 Thread Dennis van Dok (Software Engineer)
Package: wnpp
Severity: wishlist
Owner: "Dennis van Dok (Software Engineer)" 


* Package name: trustmanager
  Version : 3.0.5
  Upstream Author : Joni Hahkala 
* URL : https://twiki.cern.ch/twiki/bin/view/EGEE/TrustManager
* License : Apache 2
  Programming Lang: Java
  Description : Java TrustManager interface with grid features

 TrustManager is an implementation of the java TrustManager interface
 with implementation of cert path checking, grid namespace
 restrictions and dynamic loading of CA certs, credentials, CRLs and
 namespace restrictions. Also provided is integration into tomcat,
 axis and axis2. There are many utility classes and methods for
 certificate and proxy creation and handling in trustmanager. It can
 be used both in the server side for the server ssl handler and on the
 client side for the opening of ssl connections.



-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120118233121.26528.17053.reportbug@localhost6.localdomain6



Bug#620308: ITP: lcmaps -- Grid (X.509) and VOMS credentials to local account mapping service

2011-03-31 Thread Dennis van Dok (Software Engineer)
Package: wnpp
Severity: wishlist
Owner: "Dennis van Dok (Software Engineer)" 


* Package name: lcmaps
  Version : 1.4.28
  Upstream Author : Nikhef Grid MW Security 
* URL : 
http://www.nikhef.nl/pub/projects/grid/gridwiki/index.php/Site_Access_Control
* License : Apache-2.0
  Programming Lang: C
  Description : Grid (X.509) and VOMS credentials to local account mapping 
service

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.

It is a highly configurable pluggable interface, and many plugins are
available to tailor almost every need. Since this is middleware, it
does not interact with the user directly; to use it in a program please
see the lcmaps-interface package.
 



-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110331215926.8974.27983.reportbug@localhost6.localdomain6