Bug#1060034: ITP: python-openai -- OpenAI Python API library

[Sam Hartman]

> "Mo" == Mo Zhou  writes:

Mo> On 1/5/24 11:45, Ansgar wrote:
>> Then the package should be in main.
>> 
>> We do not require external software to be free as well, be that
>> Web APIs provided by Github, Twitter, or the NVidia firmware
>> required for Nouveau, microcode or storage/keyboard/sound/printer
>> firmware required for Linux, ...  We would have to move pretty
>> much everything to contrib if that was the case.
Mo> OK. It seems that I misunderstood it all the time. Mailed
Mo> ftp-master to reject so I can change the section and reupload.


Also, I thought that there were several open-source implementations of
this API, including from llama.cpp and ctransformers among others.  My
impression was the OpenAI API had become kind of a standard for gluing
something like text-generation-webui to a hosted model not running
locally.
Or is that some *different* OpenAI API?

Bug#1031634: ITP: gum -- A tool for glamourous shell scripts

[Sam Hartman]

> "Antonio" == Antonio Terceiro  writes:

Antonio> On Wed, Feb 22, 2023 at 09:24:29AM -0700, Scarlett Moore wrote:
>> 
>> On 2/21/23 15:03, Ryan Kavanagh wrote:
>> > On Sun, Feb 19, 2023 at 09:01:56AM -0700, Scarlett Moore wrote:
>> > > Description : A tool for glamourous shell scripts
>> > > 
>> > > A tool for glamorous shell scripts. Leverage the power of
>> Bubbles and > > Lip Gloss in your scripts and aliases without
>> writing any Go code!  > This long description does not provide
>> users with enough information to > understand what the package
>> does. What are "Bubbles" and "Lip Gloss" in > a shell script?
>> What is a "glamourous shell script"?
>> > 
>> > It would be helpful if the package's long description satisfied
>> §3.4.2 > of the Debian Policy Manual [0]:
>> > 
>> > The description field needs to make sense to anyone, even
>> people who > have no idea about any of the things the package
>> deals with. [3]
>> > 
>> > [...]
>> > 
>> > [3] The blurb that comes with a program in its announcements
>> and/or > README files is rarely suitable for use in a
>> description. It is > usually aimed at people who are already in
>> the community where the > package is used.
>> > 
>> > Best wishes, > Ryan
>> > 
>> > [0]
>> 
https://www.debian.org/doc/debian-policy/ch-binary.html#the-extended-description
>> > 
>> 
>> The package description will be this or close to it:

Antonio> That is just too long, please don't.

>>  A tool for glamorous shell scripts. Leverage the power of
>> Bubbles  (https://github.com/charmbracelet/bubbles) and Lip Gloss
>>  (https://github.com/charmbracelet/lipgloss) in your scripts and
>> aliases  without writing any Go code!   .   Tutorial  .   Gum
>> provides highly configurable, ready-to-use utilities to help you
>> write  useful shell scripts and dotfiles aliases with just a few
>> lines of code.

Antonio> This last paragraph above looks like a good enough package
Antonio> description.  Save everything else for an upstream README
Antonio> installed on /usr/share/doc/gum/, or some other type of
Antonio> documentation.

I disagree.
I should not have to chase down links to  websites to understand a
description
Please include a phrase or two describing each of bubbles and gloss.

Bug#1029842: ITP: randombytes -- Library generating fresh randomness

[Sam Hartman]

> "Jan" == Jan Mojzis  writes:
Jan> If I understand it correctly, CC0-style public-domain
Jan> declaration in debian/copyright solves the problem.  (learned
Jan> here:
Jan> https://lists.debian.org/debian-mentors/2017/09/msg00171.html)

I'm not entirely sure I agree with Don, and he was also being short.
I agree that a cc0 style declaration made by the original author makes
everything fine.
I do not think you can make a cc0 style declaration on behalf of someone
else.


signature.asc
Description: PGP signature

Bug#1029842: ITP: randombytes -- Library generating fresh randomness

[Sam Hartman]

> "Jan" == Jan Mojzis  writes:

* Package name: randombytes
  Version : 20230126
  Upstream Author : Daniel J. Bernstein
* URL : https://randombytes.cr.yp.to/
* License : Public domain

Public domain is problematic  as a license.
At least under US copyright law, there are very few circumstances when
something can actually be public domain.
One example is software written by US government employees.
But I don't think any of those circumstances apply to this library.
So I'm not sure the license is okay.

I'll  also admit to being skepticle of the utility of such a library
given the getrandom() API in libc.

Bug#1024547: ITP: sparrow -- Bitcoin wallet with a focus on privacy and usability

[Sam Hartman]

> "Craig" == Craig Raw  writes:


Craig> I assume the next step is to upload these two files, but I'm
Craig> uncertain of where or how to do this.

No, probably the next step is to make sure all the dependencies are
packaged in Debian
and then to generate a Debian format source package that generates debs
similar to those.

See https://www.debian.org/doc/manuals/maint-guide/


That's probably targeted at packaging software written in C.
You probably will want to look at the Debian Java team's pages
https://wiki.debian.org/Teams/JavaPackaging

for how they do things
and of course the developers reference for procedures on things like
sponsorship (which you will need since you are not a Debian developer)
https://www.debian.org/doc/manuals/developers-reference/

Bug#1024547: ITP: sparrow -- Bitcoin wallet with a focus on privacy and usability

[Sam Hartman]

> "craig" == craig   writes:

craig> Inclusion into the Debian repository is a precursor to
craig> inclusion into Tails, which has been broadly requested in the
craig> Bitcoin community.  Sparrow is already released as a .deb
craig> package (see https://sparrowwallet.com/downloads/) as part of
craig> the standard release process.  I intend to maintain this
craig> package going forward.

In the past we've had a bit of trouble with bitcoin wallets in Debian
when security issues emerged.  If this package makes it into Debian
stable, will you be able to provide security support for the version in
stable without upgrading to new upstream versions for the release
lifetime of stable?


signature.asc
Description: PGP signature

Bug#1020946: ITP: stripe -- Python bindings for the Stripe API

[Sam Hartman]

> "Mathias" == Mathias Behrle  writes:
Mathias> Programming Lang: Python Description : Python bindings for
Mathias> the Stripe API

Yet no where in your description do you describe what stripe is.

I'd recommend that an API description describe what the API is good
for.  And I should be able to figure that out without going and chasing
down your links.
Some paragraph like
Stripe is a web service that .

Think of it this way.  If I do a  apt-cache search for some important
key word related to what the stripe web service is good for, I should
find your API package so I can consider whether Stripe solves my
problem.

Bug#991859: Is a different opinion about a license a case for the ctte?

[Sam Hartman]

[I  accidentally sent this as a private reply earlier this morning
 before Phil's message.]
 
 TL;DR: you don't have any recourse that is appropriate for this
 situation.
 All the hammers are bigger than your nail.

 > "Andreas" == Andreas Tille  writes:

 Andreas> Hi folks, before I follow the advise how to refer a
 Andreas> question to the CTTE[1] I'm wondering whether licensing
 Andreas> questions are also a topic here.  I admit I'm a bit unsure
 Andreas> whether this minor issue about a license is really worth
 Andreas> that even more people spent time into it.  I'm demotivated
 Andreas> myself by no progress in something I would consider
 Andreas> nitpicking about a non-issue.  But I would like to use this
 Andreas> as a general example to know whether CTTE could be of help
 Andreas> in licensing questions.

 The secretary ruled that the CT cannover overrule a delegate acting in
 their delegated responsibility,
 so no the CT cannot overrule ftpmaster.

 The CT could give advice to ftpmaster, especially if ftpmaster requested
 that advice.
 I'd expect the CT would be reluctant to give non-technical advice.

 The CT could set *technical policy* and I'd expect delegates would
 generally be expected to follow reasonable technical policy established
 by the CT or be accountable to the DPL and membership at large.
 However, I don't really think that license standards are technical
 enough to be technical policy.

 ftpmaster could establish an appeals procedure.

 The DPL could establish another set of delegates for setting license
 policy and separate that out from the ftpmaster delegation.
 I.E. someone sets license policy, and ftpmaster interprets it.
 That said, some questions could not be separated.
 In particular, because of liability concerns, if ftpmaster believes
 something is not redistributable, it would be highly inappropriate to
 ask them to redistribute it in the current Debian liability model.

 Any of this could be handled by a GR.

Bug#1013132: ITP: BabaSSL -- BabaSSL is a base library for modern cryptography and communication security protocols.

[Sam Hartman]

> "Stephan" == Stephan Verbücheln  writes:

Stephan> As far as I understand it, the main point of BabaSSL is to
Stephan> add support for Chinese developed ciphers and algorithms.

It looked like there were two main points.
The first was in fact these ciphers.
I don't think that's a good reason for including in Debian because it
looks like OpenSSL is interested in adding these ciphers long-term, and
that appears a much better strategy for us as a ddistribution.

However there are some other features from the ITP:

-Support NTLS (formal GM dual-certificate protocol) handshake processing, 
according to GB/T 38636-2020
TLCP
-QUIC API support
-Support delegated credentials, according to draft-ietf-tls-subcerts-10

I don't recognize NTLS
and presumably since draft-ietf-tls-subcerts is a working group draft it
will be possible to get into OpenSSL eventually.

Bug#994458: ITP: anymarkup -- Parse or serialize any markup format in Python

[Sam Hartman]

> "John" == John Paul Adrian Glaubitz  writes:

Description : Parse or serialize any
John> markup format in Python

John> Parse or serialize any markup. Currently supports INI, JSON,
John> JSON5, TOML, XML and YAML.


I'd find it helpful if the description were improved to indicate that
this is for object serialization languages.
When I ran across the one line description I was expecting html,
markdown, rest--a pandoc competitor of some kind.

--Sam

Bug#974678: ITP: openh264 -- H.264 encoding and decoding

[Sam Hartman]

> "Bastian" == Bastian Germann  writes:

Bastian> There are H.264 patents that are applicable. I do not know
Bastian> how the existing H.264 implementations in Debian handle
Bastian> this, e.g. x264 or ffmpeg. According to the legal FAQ,
Bastian> these seem to be ignored.

I suspect you meant to say that there are H.264 patents that may be
applicable and that Debian should evaluate this risk using its normal
proocesses and policies for looking at software patents.

THOSE PROCESSES DO NOT INVOLVE debian-legal.  Discussing patents in a
public forum may result in speculative communication--like the assertion
above where you said that patents are applicable and where you probably
meant to say that the patents may be applicable--being produced in
response to allegations of patent infringement.
That harms Debian.
Thus, we have a policy that we discuss patents only in privileged
communication.
See https://www.debian.org/legal/patent


and if you are concerned about a specific patent risk, write to
pate...@debian.org.


signature.asc
Description: PGP signature

Bug#989085: ITP: gamescope -- micro-compositor for games

[Sam Hartman]

> "Stephan" == Stephan Lachnit  writes:

Stephan> BSD-2-Clause Programming Lang: C Description :
Stephan> micro-compositor for games

Stephan> Will maintain in Games team.

Stephan> Description on GitHub:

Stephan> In an embedded session usecase, gamescope does the same
Stephan> thing as steamcompmgr, but with less extra copies and
Stephan> latency:

That description isn't good enough that I can tell what this is without
going and doing a bunch of additional research.
I'd recommend improving significantly so someone can tell from the
package description whether they want the package.

Bug#953378: enough conflict

[Sam Hartman]

> "Melanie" == Melanie Frost  writes:

Melanie> The volunteer was elected as a community representative and
Melanie> he's been hounded ever since.  It looks like he asked
Melanie> people to stop these games, he resigned and he was still
Melanie> chased.

The issue is that Daniel is still chasing us.
In this specific instance, I responded because Daniel filed an ITP.
If Daniel resigned and stopped interacting with the Debian community, we
would be a lot happier, and I would not have chosen to respond this way.

The primary issue from Debian's side is that Debian has asked someone to
leave--to stop interacting.  And yet they are still interacting by doing
things like filing ITPs.  We are not chasing anyone.  We are responding
and reacting to being chased on websites like debian.community, in our
own BTS, and in other fora.  We are responding to being chased by having
messages bcc'd to large numbers of our contributors even after we have
banned someone from posting to our lists.  In some cases, this has been
done by Daniel.  In other cases this has been done by people using
anonymous accounts using techniques that are very similar to techniques
described on a website run by Daniel.  We reject these forms of
interaction.  If it were not for these forms of interaction, we would be
much less vocal/much less interested in making public statements.

--Sam

Bug#953378: Retitling to RFP

[Sam Hartman]

control: retitle -1 RFP: rake_nltk -- RAKE implemented in Python for nltk
control: noowner -1

Dear Daniel:

As you are aware, you have been expelled from the project as a Debian
Developer and then later removed from the Debian Maintainer
keyring in response to ongoing concerns with your behavior.

For these reasons, it is not appropriate for you to maintain packages.
As Project Leader with concurrence of two members of the ftpmaster team,
I confirm that Debian does not welcome you as a package maintainer.  I
request that anyone maintaining a package based on packaging you have
prepared audit that packaging as if it comes from an external source.
Since you cannot be a package maintainer, I am retitling this bug to RFP
instead of ITP.


Moreover, it is inappropriate for you to describe yourself as a Debian
Developer, as you did in your message filing the ITP.  Constitution
section 3.2 notes that the Project Leader's Delegates (in this case the
account managers) may expel developers; in your case this has happened.
So, you must not describe yourself that way or represent yourself as
speaking on behalf of the Debian Project.  Without limitation to other
circumstances, this includes when interacting with the Debian community,
its members, the BTS, and (without limitation) other aspects of the
community.  Such misrepresentations are unacceptable behavior in our
community.

In response to some of the same actions that ultimately ended up in your
key being removed from the maintainer's keyring, you were banned from
all our lists.
I reviewed how to respond to this ITP with members of ftpmaster, members
of the account manager team and members of the community team.
As part of that discussion, the question came up as to whether you were
welcome at all in our community.
With the concurrence of members of the account managers, ftpmaster, and
community team, I conclude that you are not welcome in the Debian
Project.
Please stop all interactions with our lists, our BTS, our forums,
salsa.debian.org, and any other Debian Project communications channels.
Allowing your activity and presence in our community would only
support behavior that is not welcome in our community--behavior that you
have declined to stop despite multiple requests from multiple parties
over an extended period of time.


As a general rule, the project avoids discussing expulsions in public.
However, your choice to represent yourself as a Debian Developer and to
attempt to act as a Debian Developer after you have been expelled put
the project in a position where we have chosen to make an exception to
that general rule so that our community can understand the situation and
understand that we do value acting to make Debian a place where people
can work free from disruption or harassment.

Sam Hartman
Debian Project Leader


signature.asc
Description: PGP signature

Bug#951710: ITP: microsoft-authentication-extensions-for-python -- Microsoft Authentication extensions for MSAL for Python

[Sam Hartman]

The description should describe what MSAL is.

Bug#951539: ITP: bruteforce-wallet -- Try to find a password of a encrypted wallet file

[Sam Hartman]

Might I suggest that wallet is kind of generic and I'm aware of a number
of different tools out there that claim to be wallets of various kinds.
I think the description should do a better job of scoping which wallets
this is good for.

Bug#942132: ITP: python-nest-asyncio -- Patch asyncio to allow nested event loops

[Sam Hartman]

> "Diego" == Diego M Rodriguez  writes:

Diego> nested. This presents a practical problem: When in an
Diego> environment where the event loop is already running it's
Diego> impossible to run tasks and wait for the result.

The above description should be improved.
Because it's fairly easy to  run a task and wait for the result:

await coroutine_or_task
will run a coroutine or task and await the result within any async
function.

You perhaps mean that it is difficult for non-asynchronous code to run
tasks and wait for the result.
If so, please say that.


--Sam

Bug#941708: ITP: nextcloud-server -- Nextcloud folder synchronization tool (server)

[Sam Hartman]

I think that nextcloud-server-installer would be a better package name.
Also, presumably you are targeting the contrib section rather than the
main section.

How would you feel about an actual packaging of the server (rather than
an installer) that used fastrack.debian.net?
Fastrack is intended to handle products where the security lifecycle is
too short for Debian releases.

--Sam

Bug#922952: ITP: simdjson -- Parsing gigabytes of JSON per second

[Sam Hartman]

I don't know about official policy, but I think you could make your bug
not RC by detecting whether the current system can support the package
in some reasonable wail and failing more gracefully than with SIGILL.

It's not a requirement that all packages work on all systems.
Open-vm-tools doesn't do squat if you aren't running on top of vmware;
pcscd is remarkably useless without a smartcard reader; etc.
I think it ought to be fine to have a package that is only useful with
some given hardware provided that  you're reasonable about detecting
requirements, and that  you don't place stronger requirements than are
actulaly needed by your package.

--Sam

Bug#835086: RFP: nextcloud -- self-hosted cloud services

[Sam Hartman]

> "Xavier" == Xavier Bestel  writes:

Xavier> Le mardi 20 septembre 2016 à 19:38 +0200, Moritz Mühlenhoff
Xavier> a écrit :
>> On Mon, Aug 22, 2016 at 12:02:59PM +0200, Xavier Bestel wrote:
>> > 
>> > Package: wnpp > Severity: wishlist
>> > 
>> > * Package name: nextcloud
Xavier> [...]
>> > Given that Nextcloud is an Owncloud fork, with the same people
>> > behind it, and that Owncloud upstream has always had a
>> difficult > relationship with distro maintainers, there may be
>> problems for > packaging that correctly.  > But Nextcloud is
>> still a highly relevant package for Debian.
>> 
>> Nack. It's not an important package if we can't support it
>> properly.  Let's not repeat the owncloud disaster.

Xavier> OK, I understand the "official" debian point of view.

I don't think this is an official Debian POV, simply the opinion of some
Debian contributors...  Well, I think it is the official Debian POV that
in order to include a package, we need to be able to support it.
Whether we will or will not be able to support nextcloud is up to
interpretation.

>From a user standpoint, having something that has the functionality of
opencloud/nextcloud is quite important in the enterprise space.
However, we do need to be able to get things to work.

--Sam

Bug#595817: pam-ssh-agen-auth deb package

[Sam Hartman]

I have not looked at the specifics of this package.
I know that I want something that has a similar user interface for sudo.
I have no idea though whether this implementation is any good and don't
have time to investigate.

Bug#761868: ITP: moonshot-gss-eap -- A GSS-API Mechanism for the Extensible Authentication Protocol

[Sam Hartman]

package: wnpp
severity: wishlist
owner: hartm...@debian.org
x-debbugs-cc: debian-de...@lists.debian.org


source: git://git.project-moonshot.org/mech_eap.git
license: BSD-3-Clause
Description: Project moonshot provides federated access to a wide range
of applications.  This package adds a GSS-API mechanism supporting EAP
authentication and provides the core of Moonshot authentication and
authorization.  This package provides federated access for applications
such as Ssh, NFS, LDAP and IMAP.


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/tslioknlpax@mit.edu

Bug#760411: ITP: moonshot-ui -- Project Moonshot Identity Manager

[Sam Hartman]

package: wnpp
severity: wishlist
owner: hartm...@debian.org

URL: http://www.project-moonshot.org/
source: git://git.project-moonshot.org/moonshot-ui.git
license: BSD-3-Clause
Description: This package manages the Moonshot identity store,
 permitting users to add and remove identities as well as to select which
 identity is used ith a given service.

--Sam


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/tslppfc1pxm@mit.edu

Bug#759511: ITP: moonshot-ui -Project Moonshot's Identity Selector

[Sam Hartman]

package: wnpp
owner: hartm...@debian.org
severity: wishlist

URL: http://www.project-moonshot.org/
source: git://git.project-moonshot.org/moonshot-ui.git
License: BSD-three-clause
Description: Project Moonshot provides  federated access to services
combining the best of EAP, RADIUS (over TLS), SAML and GSS-API.
 This component provides software to manage the local identity store and
 pick which identity is used for a given service.

--Sam


pgpSKo0Ub4N6R.pgp
Description: PGP signature

Bug#759398: ITP: trust-router - Dynamically configure Trust Between RADIUS Realms

[Sam Hartman]

package: wnpp
severity: wishlist
owner: hartm...@debian.org


URL: git://git.project-moonshot.org/trust_router.git
http://www.project-moonshot.org/

license: bsd-3-clause

Description: The trust router establishes a DH key between two RADIUS
servers to protect a RADIUS over TLS session.  GSS-API authentication is
used between  to securely establish this key.  The trust router provides
a trusted-third-party to manage connections between RADIUS realms and to
provide information constraining what connections are permitted.

The trust router is used to connect Moonshot Service providers to
Identity Providers.


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/tsl8umaolmv@mit.edu

Bug#759159: ITP: shibboleth-resolver - Library to access the Shibboleth Attribute Resolver from Third-Party Applications

[Sam Hartman]

package: wnpp
severity: wishlist
owner: hartm...@debian.org

URL: http://www.shibboleth.org/
Source: svn https://svn.shibboleth.net/extensions/cpp-sp-resolver/trunk

Description: Shibboleth library to access Attribute Resolver
 The Shibboleth Service provider consumes information about an
 authenticated user from SAML and GSS-API , providing services such as
 attribute mapping, authorization, and attribute resolution.  This
 extension permits a third-party application to access resolved
 attributes.

License: Apache 2.0

I'm packaging this because it is a dependency of the Moonshot GSS-API
mechanism, an implementation of RFC 7055 (EAP for GSS-API).

Current work can be seen at
git://git.project-moonshot.org/shibboleth/resolver.git


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/tsl4mx134ua@mit.edu

Bug#732562: Do you need any help getting prpltwtr into debian?

[Sam Hartman]

Hi.
I'd kind of like to be using this plugin, but it's not in Debian.
It looks like it has packaging.
Anything I can do to help?

--sam


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/tslvbuzkv9q@mit.edu

Bug#647742: update

[Sam Hartman]

libradsec 0.0.5 seems stable enough to include in Debian.
I have packaging available at
git://git.project-moonshot.org/libradsec.git on the debian branch.
I want to get a review of a few things and will upload.


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/tslk3c7ehmn@mit.edu

Bug#738850: ITP: iniparser -- a stand-alone INI file reading/writing library

[Sam Hartman]

The krb5 libraries include read and write support for the krb5.conf
format, which is very similar but not identical to ini.

I would be entirely happy with the response that:

1) the krb5 profile library should be used only for modifying Kerberos
configs

2) supporting the ABI that your application expects is worth having
multiple libraries in debian that  can do the same thing.

Also, libconfuse seems to read ini files.  I don't know if it can write
them.

This message is random information; it is *not* an objection to
packaging of iniparser.


-- 
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/tslmwhukb4a@mit.edu

Bug#647742: libradsec: changing back from ITP to RFP

[Sam Hartman]

 retitle 647742 ITP: libradsec -- RADIUS over TLS/DTLS/UDP/TCP library
 owner 647742 !
 thanks

Lucas, thanks for the prod.



my apologies for not keeping the bug updated.
The current packaging status of libradsec can be found at

git://git.project-moonshot.org/libradsec.git in the debian and libradsec
branches.

There are several reasons I have not uploaded:

1) Upstream has just gotten to a point where they think things might be
stable enough

2) There were some pending ABI changes that just got merged upstream

3) The Debian packages do not include some security enhancements that
would be required for release

4) The Debian packages have been available for that time to those
libradsec users testing with Debian in a private repo.

I totally agree I should have kept the ITP bug up to date.

Also, if any user wants me to accelerate getting this into Debian,
please write here and I'm happy to do 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/tsl1u8sh4rv@mit.edu

Bug#647740: ITP: libvertfo - library abstracting event loop interfaces

[Sam Hartman]

OK, so I had not looked at what this does on win32. I think any
criticism you have of the libverto win32 interface is probably valid.
Fortunately I don't think that's being used.



-- 
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/tslwrbdkwr9@mit.edu

Bug#647742: ITP: libradsec - RADIUS over TLS/DTLS/UDP/TCP library

[Sam Hartman]

package: wnpp
severity: wishlist

URL: libradsec branch of http://www.project-moonshot.org/gitweb/radsecproxy.git
URL2: http://software.uninett.no/radsecproxy/
Description: libradsec is a library for RADIUS clients and servers
  This library features support for RADSEC (RADIUS over TLS/DTLS) as well as 
TCP and UDP transports.

License: The following license is a bit misleading because there are
GPL dependencies. So effectively libradsec is distributed under GPL2+. However, 
the intent is to remove the GPL dependencies in the near future and so the 
license will look more like
The source code is licensed under two different licenses, a 3-clause
BSD license and the GNU General Public License (version 2 or later).
Users of this library may choose which of these suits them best.


I'm packaging libradsec because Moonshot
(http://www.project-moonshot.org/) depends on it.  It has not been
formally released yet.  It's sort of related to radsecproxy that is
already in Debian in that eventually, libradsec may be used as a
library by radsecproxy. At that point it might make sense for the
libradsec and radsecproxy source packages to be combined. Today,
although they come from the same git repository, they come from
different branches and different places in the directory tree. There
are a couple of header files in common.

I cannot upload libradsec to unstable until libevent 2.x makes its way
into unstable.



-- 
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/2005174338.dec664...@carter-zimmerman.suchdamage.org

Bug#647740: ITP: libvertfo - library abstracting event loop interfaces

[Sam Hartman]

package: wnpp
severity: wishlist

URL: https://fedorahosted.org/libverto/
Description: libverto provides a common interface on top of libev, libevent, 
glib, tevent.
  The goal is to allow development of asynchronous libraries that  will work 
with whatever event loop an application happens to be using
  Features include automatic detection of which event loops are in a particular 
process space and support for writing new event loop modules.

License:
 * Copyright 2011 Red Hat, Inc.
 *
 * Permission is hereby granted, free of charge, to any person
 * obtaining a copy of this software and associated documentation files
 * (the Software), to deal in the Software without restriction,
 * including without limitation the rights to use, copy, modify, merge,
 * publish, distribute, sublicense, and/or sell copies of the Software,
 * and to permit persons to whom the Software is furnished to do so,
 * subject to the following conditions:
 *
 * The above copyright notice and this permission notice shall be
 * included in all copies or substantial portions of the Software.
 *
 * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
 * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
 * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
 * NONINFRINGEMENT.  IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
 * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
 * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
 * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
 * SOFTWARE.


I'm packaging this because it's a dependency for MIT Kerberos 1.10.
It's kind of annoying but libverto has not yet been released so I'll
probably end up packaging a git snapshot. I'll prod upstream and see
if a release can be caused to happen.



-- 
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/2005173408.0b7a14...@carter-zimmerman.suchdamage.org

Bug#647742: ITP: libradsec - RADIUS over TLS/DTLS/UDP/TCP library

[Sam Hartman]

 Faidon == Faidon Liambotis parav...@debian.org writes:

Faidon Hi Sam, Hope you're well.

Faidon Are you planning on putting the packaging efforts for this
Faidon on git somewhere (e.g. collab-maint?). If so, I'd be happy
Faidon to contribute, if help is needed, either now or when the
Faidon merging effort with radsecproxy starts.

Packaging is on the debian branch of
http://www.project-moonshot.org/git/radsecproxy.git

I'm certainly happy to give you a git account there. I suspect once we
fix the remaining security issues for the moonshot gss mechanism we'll
probably be using moonshot authentication for our moonshot work.  I'd
rather not have to use both Alioth credentials and whatever Moonshot
credentials we end up with in the same project so I'd probably want a
compelling reason before moving the debian packaging to a different
place than the rest of the moonshot sources.



-- 
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/tslehxmnxz9@mit.edu

Bug#566346: ITP: krb5-appl - Kerberos applications and clients

[Sam Hartman]

package: wnpp
severity: wishlist
owner: hartm...@debian.org

name: krb5-appl
URL: http://web.mit.edu/kerberos/dist/krb5-appl
License: MIT Kerberos license 
(roughly MIT license plus a requirement that if you modify the
software you must mark it as modified)
description: Contains fairly ancient versions of telnetd, ftpd, rsh and
rlogin that support Kerberos authentication

Up until the upcoming Kerberos 1.8 release, these applications were part
of the main krb5 tree.  They are kind of old and crufty, but attempts to
kill them off have met with users (and Debian users) who say they are
still valuable in certain environments.  Reasons cited include that the
code base is simpler than things like ssh, it works and is in use, etc.
My belief that the security of the rsh and rlogin programs is quite
good, although the telnet and telnetd are well below current security
standards.

However upstream krb5 doesn't want to maintain the applicatinos as part
of the main source tree.  So, they are being split out.  Since Debian
users still want them, I'm going to package them.  They've been in
Debian for years already, so I think this should not be a problem.

To look at the WIP packages see
git://git.debian.org/git/pkg-k5-afs/debian-krb5-appl.git


pgpRQTHS9XpyD.pgp
Description: PGP signature

Bug#516750: ITP: rsplib -- Implementation of the IETF's Reliable Server Pooling (RSerPool) standard defined in RFCs 5351 to 5356.

[Sam Hartman]

This is a nit, but it' seems inappropriate to refer to rsrvpool as a
standard in your package description.  These RFCs were published as
experimental  because of serious concerns raised at the IESG level.

It would be better to describe it as the reliable server pool
experiment or protocol rather than standard.

--Sam




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

Bug#483382: ITP: barnowl -- curses based jabber, zephyr and IRC client

[Sam Hartman]

package: wnpp
severity: wishlist

Barnowl can be obtained from http://barnowl.mit.edu/.  It is a fork of
owl, which is already in Debian.  Barnowl adds Jabber and IRc support
and fixes many bugs providing a new extensibility architecture.

I've discussed my plans to package barnowl with the Owl maintainer
(Mark Eichin).  he supports barnowl being packaged for Debian.  At
some future point it may be desirable to remove owl.  Today though we
both believe that would be a big transition for the owl community

The main body of barnowl is distributed under the following license:

From owl.c:

/*  Copyright (c) 2004 James Kretchmar. All rights reserved.
 *
 *  Redistribution and use in source and binary forms, with or without
 *  modification, are permitted provided that the following conditions are
 *  met:
 *  
 ** Redistributions of source code must retain the above copyright
 *  notice, this list of conditions and the following disclaimer.
 *  
 ** Redistributions in binary form must reproduce the above copyright
 *  notice, this list of conditions and the following disclaimer in
 *  the documentation and/or other materials provided with the
 *  distribution.
 *  
 ** Redistributions in any form must be accompanied by information on
 *  how to obtain complete source code for the Owl software and any
 *  accompanying software that uses the Owl software. The source code
 *  must either be included in the distribution or be available for no
 *  more than the cost of distribution plus a nominal fee, and must be
 *  freely redistributable under reasonable conditions. For an
 *  executable file, complete source code means the source code for
 *  all modules it contains. It does not include source code for
 *  modules or files that typically accompany the major components of
 *  the operating system on which the executable file runs.
 *  
 * 
 *  THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
 *  IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
 *  WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR
 *  NON-INFRINGEMENT, ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE
 *  LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
 *  CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
 *  SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
 *  BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
 *  WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
 *  OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN
 *  IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 */


In addition, barnowl includes a modified copy of XML::Stream ,
Net::Jabber and Net::XMPP.  They are distributed under the LGPL.



pgpkMZFAUiVj6.pgp
Description: PGP signature

Bug#242251: ITP: user-friendly -- automatic helper to manage Debian

[Sam Hartman]

How do you plan to give more permissions to local users?

Bug#68243: Progress of packaging linphone

[Sam Hartman]

I'd like to use this program and was just wondering what
problems/progress you had made with this ITP.

Bug#156287: Advice on Drip (ITP #156287)

[Sam Hartman]

I continue to believe that like other packages already in Debian,
supporting libdvdcss if it is found is perfectly reasonable.  If you
manage to dlopen it and find the right symbols, use it.

If someone complains, we can reevaluate the situation at that point.

Bug#142065: ITP: cyrus2-sasl-mit - MIT Kerberos modules for sasl2

[Sam Hartman]

package: wnpp
severity: wishlist

I'm planning on packaging libsasl2-gssapi-mit, a version of the GSSAPI
plugin for libsasl2 compiled against MIT Kerberos.

This package has the same source as cyrus-sasl2, but different build
environment and options.  It's not really possible to avoid having two
source packages, even given crypto-in-main.


This is the same setup we have for libsasl7 for all the same reasons.


I sent the SASL maintainer mail a while back and received no objection.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#128888: ITP: ssh-krb5 - A version of OpenSSH patched to support Kerberos Authentication

[Sam Hartman]

package: wnpp
severity: wishlist

Hi.  AS discussed below, I intend to package OpenSSH using the current
Debian sources with patches to allow krb5 authentication.  I will use
the patches available at
http://www.sxw.org.uk/computing/patches/openssh.html.  These patches
attempt to comply with draft-ietf-secsh-gss-keyex along with some of
the more common other types of Kerberos authentication.

The Kerberos packaging will follow guidelines agreed on by Debian
kerberos package maintainers and included in
/usr/share/doc/krb5-config/packaging-guidelines.txt.gz.  The package
will likely build withe either Heimdal or MIT Kerberos, although the
version uploaded to non-us will  be compiled against MIT Kerberos.  

Below is previous discussion on this package attempting to justify the
need for yet another ssh package in Debian.



---BeginMessage---

Hi.  I sent mail to [EMAIL PROTECTED] about tthis a while back.
I heard no response.  It is my intent to ITP ssh-krb5 as a package at
priority extra that conflicts with the existing ssh.  I will probably
store configuration files in /etc/ssh rather than /etc/ssh-krb5
because I believe that some time after woody releases we will be able
to get these changes folded into OpenSSH upstream and then hopefully
into the main Debian ssh packages.

This is a heads up for the Kerberos and Ssh community in Debian.





---BeginMessage---


So I suspect I'm not the only one on this list that would like
Kerberized ssh in Debian.  However ssh is somewhat of a moving target;
here are the things we probably want to support:

* The ssh.com sshv1 Kerberos5 protocol (used by MIT among others)
* The ssh Kerberos4 protocol (used by CMU and others) (Is this the
same  as the krb4 in openssh?)
* draft-ietf-secsh-gss-keyex (standards track protocol)
* The krb5 support in sxw's patches to Openssh 2.5.2 (does anyone use
* this?
   no would be a really really convenient answer)

I propose that I talk to the ssh maintainer and get permission to ITP
an ssh-krb5 that supports the first three listed protocols.I believe
code will exist to do that fairly soon.  I'd rather do that than fold
in Kerberos support because it is so much of a moving target right now
and because it would be asking the ssh maintainer to maintain a lot of
third-party patches.


Reasonable?

___
Debian-kerberos mailing list
[EMAIL PROTECTED]
http://mailman.boxedpenguin.com/mailman/listinfo/debian-kerberos
---End Message---
---End Message---

Bug#108942: The saga of cyrus2-imapd continues

[Sam Hartman]

 David == David D Kilzer [EMAIL PROTECTED] writes:

David I finally got cyrus2-imapd to authenticate an account, but
David I had to use sasldb instead of PAM for
David sasl_pwcheck_method in /etc/imapd.conf.

David It appears that until PAM-0.74 is available in unstable,
David cyrus2-imapd won't be able to authenticate using it.  I
David thought about filing a new upstream version bug against
David libpam0g, but I know there has been some discussion about
David how to handle new versions of PAM in Debian.  I just can't
David seem to find the correct mailing list archive or web page
David that describes this.

Disbelieve.  It can be handled the same way as cyrus 1.x.

Bug#118427: TP: epo -- Miner mode to reduce the labour to edit code

[Sam Hartman]

 Raul == Raul Miller [EMAIL PROTECTED] writes:

Raul On Tue, Nov 06, 2001 at 09:16:19AM -0500, Peter S Galbraith
Raul wrote:
 Raul, why are you so quick to dismiss this?  You state it like
 it was a matter of fact.  Is this documented anywhere?

Raul I didn't dismiss it.  [And, what is it that you want
Raul documentation on?]

Raul Look at the situation this way: the GPL restricts the
Raul distribution of emacs, not that of independently written
Raul code.  The question asked was whether it was legal to
Raul distribute some non-gpled elisp code -- and the answer has
Raul to have a lot to do with how closely the code is tied to
Raul gpl'd emacs (gnu emacs vs. xemacs, ferinstance).

How is this different distributing a version of ripem (sp?) that
required GMP?  My understanding is that the FSF argued that the
distribution was illegal because it had the effect of distributing an
application that violated the GPL, by linking non-GPL code to a GPL
library.  I believe they objected even to source distributions.  For
details on this situation check the gnu.misc.discuss archives, I think
around 1994.

Bug#108942: ITP: cyrus2-imapd -- CMU Cyrus project mail system, version 2

[Sam Hartman]

 Henrique == Henrique de Moraes Holschuh [EMAIL PROTECTED] writes:

Henrique Kerberos will not be present in the first versions of
Henrique the package, and unless someone shows up to help test
Henrique it, support may never be included.

I'd be happy to help as Kerberos maintainer, however I don't think
that the Kerberos support is useful.  I'd recommend against using it.
It is only authorization support; you use SASL for Kerberos
authentication.  Actually, you may want to use Kerberos for POP, but
we'll take a look at that later, and it might be easier to just not
deal.

I may send you a patch to the unix authorization stuff to allow
usernames including . if that isn't allowed.  I've discussed the patch
with leg and he indicated he would accept if I sent to him so I would
send to both of you at the same time.  This is the only issue most
people run into with Kerberos.

Bug#97300: kerberos-configs going to non-us after all

[Sam Hartman]

James said he'd be happier if I uploaded to non-us, so I did.

Bug#97300: ITP: kerberos-configus - package to manage configuration files for multiple Kerberos implementations

[Sam Hartman]

package: wnpp
severity: wishlist


In an attempt to solve bug #80365, I found that we needed
infrastructure to manage config files for Kerberos versions 4 and 5.
We have two implementations of each version of Kerberos in Debian
currently.  The can in general share the same config files, so it is
desirable not to lose configuration information when removing/purging
one implementation for another.

Thus, I have authored kerberos-configs, a package to manage the config
files.  There is a version available (referenced within the bug) that
supports krb5.  The krb4 support will be added once krb5 support is
finalized.

I will coordinate with the other maintainers of Kerberos
implementations to upload this package.

It's getting to a point where it is worth ITping the package, so I can upload 
once coordination is complete.  The package is released under the GPL, so it 
should be fine for non-us.  

Bug#92043: ITP: libsasl-nonus-mit -SASL crypto plugins compiled against MIT Kerberos

[Sam Hartman]

package: wnpp
severity: wishlist


Hi.  I will be packaging a version of the Cyrus SASL library that will
build libsasl-gssapi-mit and libsasl-krb4-mit for non-us.  These will
be Kerberos SASL modules built against MIT Kerberos instead of
Heimdal.

I have talked to the current libsasl-modules-nonus maintainer, and he
is aware of this and we have discussed how to handle the naming issues.

The GSSAPI plugins are mostly interoperable between MIT and Heimdal,
although some versions of Heimdal do not currently support the 3DES
GSSAPI that MIT has been shipping.