Bug#921954: gnulib

[Simon Josefsson]

Jonas Smedegaard  writes:

> I am happy that gnulib is in good hands.
>
> I've moved on to other challenges, and have no interest in working on
> gnulib now.  That said, you are welcome to try nudge me if some concrete
> task emerges where you image I might be of help.

Thank you for support!

Boyuan Yang  writes:

> Thanks for your work; I am okay with the changes. For git bundle
> reproducibility, seeking advice from Debian people in the reproducible-
> builds project may be helpful. With the changes in project structure, it
> might be useful to provide documents about how to use the updated gnulib
> Debian package for other Debian software packagers.

Definitely, my blog post [1] illustrates how it can be done, but the
details for a Debian packager is sketchy.  I should summarize how to
convert a Debian package from a traditional 'make dist' tarball that
includes gnulib to a 'git-archive' based approach that uses gnulib from
the Debian package, maybe as a debian-devel post.

However I don't think it is wise to do that for packages that are
validating PGP signatures of the existing tarball and there is an
upstream that doesn't provide PGP signed 'git-archive' releases.  We can
nudge upstream's to sign 'git-archive' exports of their projects,
though.

/Simon

[1] 
https://blog.josefsson.org/2024/04/13/reproducible-and-minimal-source-only-tarballs/


signature.asc
Description: PGP signature

Bug#921954: gnulib

[Simon Josefsson]

Hi

You may have noticed I adopted gnulib and have made an upload to
experimental.  I am happy to have this team maintained, so feel free to
join the effort -- I added Boyuan to Uploaders: since you've been doing
QA uploads for some time, but happy to add others too.

If you don't object, I will upload to unstable in a couple of days if
nothing comes up.  Relevant reading material on the changes I did for
this package:

https://salsa.debian.org/debian/gnulib/-/blob/debian/sid/debian/README.source
https://blog.josefsson.org/2024/04/13/reproducible-and-minimal-source-only-tarballs/

What do you think?  I hope I'm not stepping on anyone's toes here.  The
package was orphaned and is a critical component to be able to build
source-only tarballs for other packages in Debian.

/Simon

Simon Josefsson  writes:

> Hi. I noticed gnulib in Debian was orphaned. I work upstream on gnulib
> and intend to adopt it in Debian, but I’m happy to co-maintain it. My
> plan is to keep it updated to latest upstream version, and see if we
> can offer some way for it to be used to bootstrap various projects
> that depend on vendored gnulib code.
>
> /Simon


signature.asc
Description: PGP signature

Bug#921954: Volunteer to adopt this

[Simon Josefsson]

Hi. I noticed gnulib in Debian was orphaned. I work upstream on gnulib and 
intend to adopt it in Debian, but I’m happy to co-maintain it. My plan is to 
keep it updated to latest upstream version, and see if we can offer some way 
for it to be used to bootstrap various projects that depend on vendored gnulib 
code.

/Simon

Bug#1064397: ITP: client-desktop-shell-integration-nautilus -- Nautilus, Nemo and Caja integration of the owncloud-client

[Simon Josefsson]

Pierre-Elliott Bécue  writes:

> Package: wnpp
> Severity: wishlist
> Owner: Pierre-Elliott Bécue 
> X-Debbugs-Cc: debian-de...@lists.debian.org
>
> * Package name: client-desktop-shell-integration-nautilus
>   Version : 5.0.0
>   Upstream Contact: Frank Müller 
> * URL : 
> https://github.com/owncloud/client-desktop-shell-integration-nautilus
> * License : GPL-2
>   Programming Lang: Python, Shell, ...
>   Description : Nautilus, Nemo and Caja integration for ownCloud Client.
>
> These three extensions were originally integrated in the owncloud-client
> source package. Upstream decided to extract them to create a new repo.
>
> The package will be maintained in the owncloud-team.

Hi - how about including 'owncloud' in the package name?
'owncloud-client-desktop-shell-integration-nautilus'?  Or
'owncloud-nautilus-integration'?

/Simon


signature.asc
Description: PGP signature

Bug#1061446: ITP: cosign -- Code signing and transparency for containers and binaries

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: cosign
  Version : 2.2.2-1
  Upstream Author : The Sigstore Authors
* URL : https://github.com/sigstore/cosign
* License : Apache-2.0
  Programming Lang: Go
  Description : Code signing and transparency for containers and binaries

 Signing OCI containers (and other artifacts) using Sigstore
 (https://sigstore.dev/)!
 .
 Go Report Card
 (https://goreportcard.com/report/github.com/sigstore/cosign) e2e-tests
 (https://github.com/sigstore/cosign/actions/workflows/e2e-tests.yml) CII
 Best Practices
 (https://bestpractices.coreinfrastructure.org/projects/5715) OpenSSF
 Scorecard
 (https://api.securityscorecards.dev/projects/github.com/sigstore/cosign)
 .
 Cosign aims to make signatures **invisible infrastructure**.
 .
 Cosign supports:
 .
  * "Keyless signing" with the Sigstore public good Fulcio certificate
authority and Rekor transparency log (default)
  * Hardware and KMS signing
  * Signing with a cosign generated encrypted private/public keypair
  * Container Signing, Verification and Storage in an OCI registry.
  * Bring-your-own PKI
 .
 Info
 .
 Cosign is developed as part of the sigstore (https://sigstore.dev)
 project. We also use a slack channel (https://sigstore.slack.com)! Click
 here (https://join.slack.com/t/sigstore/shared_invite/zt-mhs55zh0-
 XmY3bcfWn4XEyMqUUutbUQ) for the invite link.
 .
 Installation
 .
 For Homebrew, Arch, Nix, GitHub Action, and Kubernetes installs see the
 installation docs
 (https://docs.sigstore.dev/system_config/installation/).
 .
 For Linux and macOS binaries see the GitHub release assets
 (https://github.com/sigstore/cosign/releases/latest).
 .
 :rotating_light: If you are downloading releases of cosign from our GCS
 bucket - please see more information on the July 31, 2023 deprecation
 notice (https://blog.sigstore.dev/cosign-releases-bucket-deprecation/)
 :rotating_light:
 .
 Developer Installation
 .
 If you have Go 1.19+, you can setup a development environment:
 .
   $ git clone https://github.com/sigstore/cosign
   $ cd cosign
   $ go install ./cmd/cosign
   $ $(go env GOPATH)/bin/cosign
 .
 Contributing
 .
 If you are interested in contributing to cosign, please read the
 contributing documentation (/CONTRIBUTING.md).
 .
 Dockerfile
 .
 Here is how to install and use cosign inside a Dockerfile through the
 gcr.io/projectsigstore/cosign image:
 .
   FROM gcr.io/projectsigstore/cosign:v1.13.0 as cosign-bin
 .
   # Source: https://github.com/chainguard-images/static
   FROM cgr.dev/chainguard/static:latest
   COPY --from=cosign-bin /ko-app/cosign /usr/local/bin/cosign
   ENTRYPOINT [ "cosign" ]
 .
 Quick Start
 .
 This shows how to:
 .
  * sign a container image with the default "keyless signing" method (see
KEYLESS.md (/KEYLESS.md))
  * verify the container image
 .
 Sign a container and store the signature in the registry
 .
 Note that you should always sign images based on their digest
 (@sha256:...) rather than a tag (:latest) because otherwise you might
 sign something you didn't intend to!
 .
cosign sign $IMAGE
 .
   Generating ephemeral keys...
   Retrieving signed certificate...
 .
Note that there may be personally identifiable information associated
 with this signed artifact.
This may include the email address associated with the account with
 which you authenticate.
This information will be used for signing this artifact and will be
 stored in public transparency logs and cannot be removed later.
 .
   By typing 'y', you attest that you grant (or have permission to grant)
 and agree to have this information stored permanently in transparency
 logs.
   Are you sure you would like to continue? [y/N] y
   Your browser will now be opened to:
 .
 
https://oauth2.sigstore.dev/auth/auth?access_type=online_id=sigstore_challenge=OrXitVKUZm2lEWHVt1oQWR4HZvn0rSlKhLcltglYxCY_challenge_method=S256=2KvOWeTFxYfxyzHtssvlIXmY6Jk_uri=http%3A%2F%2Flocalhost%3A57102%2Fauth%2Fcallback_type=code=openid+email=2KvOWfbQJ1caqScgjwibzK2qJmb
   Successfully verified SCT...
   tlog entry created with index: 12086900
   Pushing signature to: $IMAGE
 .
 Cosign will prompt you to authenticate via OIDC, where you'll sign in
 with your email address. Under the hood, cosign will request a code
 signing certificate from the Fulcio certificate authority. The subject
 of the certificate will match the email address you logged in with.
 Cosign will then store the signature and certificate in the Rekor
 transparency log, and upload the signature to the OCI registry alongside
 the image you're signing.
 .
 Verify a container
 .
 To verify the image, you'll need to pass in the expected certificate
 issuer and certificate subject via the --certificate-identity and --
 certificate-oidc-issuer flags:
 .
   cosign verify $IMAGE --certificate-identity=$IDENTITY --certificate-oidc-
 issuer=$OIDC_ISSUER
 .
 You can also pass 

Bug#1061153: ITP: sigsum-go -- tools for public and transparent logging of signed checksums

[Simon Josefsson]

> 21 jan. 2024 kl. 20:09 skrev Holger Levsen :
> 
> Hi Simon,
> 
>> On Fri, Jan 19, 2024 at 05:32:05PM +0100, Simon Josefsson wrote:
>> * URL : https://git.glasklar.is/sigsum/core/sigsum-go
>>  Description : tools for public and transparent logging of signed 
>> checksums
>> 
>> The goal of Sigsum is to provide building blocks that can be used to
>> enforce public logging of signed checksums.
> 
> do you think this would be a suitable tool to publically log all checksums of
> all Debian source and binary packages published?

Yes that would be nice. However I think we want multiple additional 
verification methods. The simplest augmentation would be to confirm that 
already existing signatures are recorded publicly via rekor. That doesn’t 
require any tooling or new private keys during signing, and help mitigate 
attackers ability to deny their actions. Cosign and sigsum are two next low 
hanging fruit but demand private key considerations. While publishers of 
packages (such as Trisquel or Debian) can be responsible for this, from the 
point of view of the consumer of packages, it would add more strength if a 
couple of external independent organizations vouch for the packages. I run one 
via the gitlab debdistutils project, but mirroring the ideas elsewhere would 
help. One key point is that any publishers packages’ aren’t trustworthy if they 
cannot be rebuilt from source and validated by a third party, and that third 
party should sign claims of what levels of verification were made, and users 
can pick a couple of entities to vouch for packages they install. Could the 
reproducible build project sign the packages you build and publish those 
signatures? I suggest using all three of GnuPG, sigsum-submit and cosign.

/Simin

> 
> 
> --
> cheers,
>Holger
> 
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
> ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
> ⠈⠳⣄
> 
> Life may not be the party we hoped for, but while we're here we might as well
> dance!

Bug#1061153: ITP: sigsum-go -- tools for public and transparent logging of signed checksums

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: sigsum-go
  Version : 1.7.1-1
  Upstream Author : The Sigsum Project Authors
* URL : https://git.glasklar.is/sigsum/core/sigsum-go
* License : BSD-2-Clause
  Programming Lang: Go
  Description : tools for public and transparent logging of signed checksums

 The goal of Sigsum is to provide building blocks that can be used to
 enforce public logging of signed checksums.
 .
 This package contains the sigsum-key, sigsum-submit, sigsum-verify,
 and sigsum-monitor command line tools.

I hope to maintain this package as part of Debian Go Packaging Team:

https://salsa.debian.org/go-team/packages/sigsum-go

/Simon


signature.asc
Description: PGP signature

Bug#1060820: ITP: golang-github-cyberphone-json-canonicalization -- JSON Canonicalization Scheme (JCS) (Go library)

[Simon Josefsson]

Hi Reinhard,

Instead of packaging golang-github-cyberphone-json-canonicalization I
uploaded a NMU for golang-webpki-org-jsoncanonicalizer to make it
provide the name that rekor expects, thereby closing this ITP bug with
this NMU upload.  See debdiff below.

What do you think about moving this package into the go-team umbrella?
I can help maintain it if you agree.

Before I understood that golang-webpki-org-jsoncanonicalizer was in
unstable (there was no ITP bug!  I though it was never uploaded) I did
some work to clean up this packaging, on my 'jas-upstream' and
'jas-debian/sid' branches in URL below.  That work is unfinished, but if
you agree, I can move this into the go-team umbrella and make an
experimental upload with updated packaging for testing.

https://salsa.debian.org/jas/golang-webpki-org-jsoncanonicalizer/-/tree/jas-debian/sid

/Simon

diff -Nru golang-webpki-org-jsoncanonicalizer-0.20210204/debian/changelog 
golang-webpki-org-jsoncanonicalizer-0.20210204/debian/changelog
--- golang-webpki-org-jsoncanonicalizer-0.20210204/debian/changelog 
2023-11-13 02:47:06.0 +0100
+++ golang-webpki-org-jsoncanonicalizer-0.20210204/debian/changelog 
2024-01-18 19:52:58.0 +0100
@@ -1,3 +1,10 @@
+golang-webpki-org-jsoncanonicalizer (0.20210204-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add link for name used by rekor.  Closes: #1060820.
+
+ -- Simon Josefsson   Thu, 18 Jan 2024 19:52:58 +0100
+
 golang-webpki-org-jsoncanonicalizer (0.20210204-1) unstable; urgency=medium
 
   * Initial release.
diff -Nru golang-webpki-org-jsoncanonicalizer-0.20210204/debian/links 
golang-webpki-org-jsoncanonicalizer-0.20210204/debian/links
--- golang-webpki-org-jsoncanonicalizer-0.20210204/debian/links 1970-01-01 
01:00:00.0 +0100
+++ golang-webpki-org-jsoncanonicalizer-0.20210204/debian/links 2024-01-18 
19:52:58.0 +0100
@@ -0,0 +1 @@
+usr/share/gocode/src/webpki.org/jsoncanonicalizer 
usr/share/gocode/src/github.com/cyberphone/json-canonicalization/go/src/webpki.org/jsoncanonicalizer


signature.asc
Description: PGP signature

Bug#1060840: ITP: golang-k8s-sigs-release-utils -- utilities for kubernetes Go release engineering (library)

[Simon Josefsson]

I managed to get this package to build, and I belive it actually is
required.  Rekor is using it for "rekor-cli version":

root@vello:~# rekor-cli version
  _   _  __   ___    _   ___
 |  _ \  | | | |/ /  / _ \  |  _ \   / ___| | | |_ _|
 | |_) | |  _|   | ' /  | | | | | |_) |  _  | | | |  | |
 |  _ <  | |___  | . \  | |_| | |  _ <  |_| | |___  | |___   | |
 |_| \_\ |_| |_|\_\  \___/  |_| \_\  \| |_| |___|
rekor-cli: Rekor CLI

GitVersion:v1.1.0
GitCommit: 4a6592612dc015f24d0700b6d274b3663d128ad8
GitTreeState:  clean
BuildDate: 2023-03-28T22:13:50Z
GoVersion: go1.20.1
Compiler:  gc
Platform:  linux/ppc64le

root@vello:~# 

This comes via sigs.k8s.io/release-utils/version that uses
github.com/common-nighthawk/go-figure for the ASCII art output.

Of course, we would have to be careful about setting the proper version
fields to not cause reproducible build problems, but I believe that is
possible using -ldflags=-X=sigs.k8s.io... parameters, compare:

https://git.alpinelinux.org/aports/tree/community/rekor/APKBUILD
https://github.com/sigstore/rekor/blob/9df89979ba08e76a3f86c0b7406a1ba90710ade6/Makefile#L58

/Simon


signature.asc
Description: PGP signature

Bug#1061050: ITP: golang-github-common-nighthawk-go-figure -- Prints ASCII art from text

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: golang-github-common-nighthawk-go-figure
  Version : 0.0~git20210622.734e95f-1
  Upstream Author : Daniel Deutsch
* URL : https://github.com/common-nighthawk/go-figure
* License : Expat
  Programming Lang: Go
  Description : Prints ASCII art from text

 Go Figure prints beautiful ASCII art from text. It supports FIGlet
 (http://www.figlet.org/) files, and most of its features.
 .
 This package was inspired by the Ruby gem artii
 (https://github.com/miketierney/artii), but built from scratch and with
 a different feature set.

I hope to maintain this package as part of Debian Go Packaging Team:

https://salsa.debian.org/go-team/packages/golang-github-common-nighthawk-go-figure

/Simon


signature.asc
Description: PGP signature

Bug#1060839: ITP: golang-github-adamkorcz-go-fuzz-headers-1 -- helper functions for Go fuzzing (library)

[Simon Josefsson]

Shengjing Zhu  writes:

>> go.sum:github.com/AdamKorcz/go-fuzz-headers-1
>> v0.0.0-20230618160516-e936619f9f18
>> h1:rd389Q26LMy03gG4anandGFC2LW/xvjga5GezeeaxQk=
>> go.sum:github.com/AdamKorcz/go-fuzz-headers-1
>> v0.0.0-20230618160516-e936619f9f18/go.mod
>> h1:fgJuSBrJP5qZtKqaMJE0hmhS2tmRH+44IkfZvjtaf1M=
>> hack/tools/go.sum:github.com/AdamKorcz/go-fuzz-headers-1
>> v0.0.0-2023032938-12e09aba5ebd
>> h1:1tbEqR4NyQLgiod7vLXSswHteGetAVZrMGCqrJxLKRs=
>> hack/tools/go.sum:github.com/AdamKorcz/go-fuzz-headers-1
>> v0.0.0-2023032938-12e09aba5ebd/go.mod
>> h1:0vOOKsOMKPThRu9lQMAxcQ8D60f8U+wHXl07SyUw0+U=
>> hack/tools/tools.go:_ "github.com/AdamKorcz/go-fuzz-headers-1"
>> hack/tools/go.mod:  github.com/AdamKorcz/go-fuzz-headers-1 
>> v0.0.0-2023032938-12e09aba5ebd
>> pkg/types/hashedrekord/v0.0.1/fuzz_test.go: fuzz 
>> "github.com/AdamKorcz/go-fuzz-headers-1"
>> pkg/types/rpm/v0.0.1/fuzz_test.go:  fuzz 
>> "github.com/AdamKorcz/go-fuzz-headers-1"
>> pkg/types/alpine/v0.0.1/fuzz_test.go:   fuzz 
>> "github.com/AdamKorcz/go-fuzz-headers-1"
>> pkg/types/alpine/fuzz_test.go:  fuzz "github.com/AdamKorcz/go-fuzz-headers-1"
>> pkg/types/cose/v0.0.1/fuzz_test.go: fuzz 
>> "github.com/AdamKorcz/go-fuzz-headers-1"
>> pkg/types/jar/v0.0.1/fuzz_test.go:  fuzz 
>> "github.com/AdamKorcz/go-fuzz-headers-1"
>> pkg/types/rekord/v0.0.1/fuzz_test.go:   fuzz 
>> "github.com/AdamKorcz/go-fuzz-headers-1"
>> pkg/types/intoto/v0.0.1/fuzz_test.go:   fuzz 
>> "github.com/AdamKorcz/go-fuzz-headers-1"
>> pkg/types/intoto/v0.0.2/fuzz_test.go:   fuzz 
>> "github.com/AdamKorcz/go-fuzz-headers-1"
>> pkg/types/tuf/v0.0.1/fuzz_test.go:  fuzz 
>> "github.com/AdamKorcz/go-fuzz-headers-1"
>> pkg/types/helm/v0.0.1/fuzz_test.go: fuzz 
>> "github.com/AdamKorcz/go-fuzz-headers-1"
>> pkg/types/dsse/v0.0.1/fuzz_test.go: fuzz 
>> "github.com/AdamKorcz/go-fuzz-headers-1"
>> pkg/types/rfc3161/v0.0.1/fuzz_test.go:  fuzz 
>> "github.com/AdamKorcz/go-fuzz-headers-1"
>> pkg/fuzz/alpine_utils.go:   fuzz "github.com/AdamKorcz/go-fuzz-headers-1"
>> pkg/fuzz/fuzz_utils.go: fuzz "github.com/AdamKorcz/go-fuzz-headers-1"
>> pkg/fuzz/jar_utils.go:  fuzz "github.com/AdamKorcz/go-fuzz-headers-1"
>> go.mod: github.com/AdamKorcz/go-fuzz-headers-1 
>> v0.0.0-20230618160516-e936619f9f18
>>
>> Would we have to patch all of these files?  Or disable building them
>> somehow?
>>
>
> Just remove these files, either via Files-Excluded in
> debian/copyright, or rm in builddir in debian/rules.

Hi.  Ftp-master quickly approved this package, so we have it in Debian
now.  Since I'm not that familiar with Go, maintaining a patch for rekor
to patch out these references to the fuzz library is harder for me than
to maintain golang-github-adamkorcz-go-fuzz-headers-1.  My preference is
to not deviate from upstream here, since adding Debian-specific patches
usually leads to problems down the road in my experience.  If you
strongly prefer to keep this package out of a Debian release, and can
help maintain the patches necessary for rekor, please push a patch to
the rekor git repository to get rid of this dependency, and open a RC
critical bug for golang-github-adamkorcz-go-fuzz-headers-1 package to
keep it ouf of testing.

/Simon

>
>> Let's see if we can develop a workaround before ftp-master approves the
>> packages...  otherwise maybe it doesn't hurt to use it anyway, and may
>> save us time maintaining patches.
>>
>> /Simon


signature.asc
Description: PGP signature

Bug#1060839: ITP: golang-github-adamkorcz-go-fuzz-headers-1 -- helper functions for Go fuzzing (library)

[Simon Josefsson]

Shengjing Zhu  writes:

> On Mon, Jan 15, 2024 at 8:51 PM Simon Josefsson  wrote:
>>
>> Package: wnpp
>> Severity: wishlist
>> Owner: Simon Josefsson 
>>
>> * Package name: golang-github-adamkorcz-go-fuzz-headers-1
>>   Version : 0.0~git20230919.8b5d3ce-1
>>   Upstream Author : Adam Korcz 
>> * URL : https://github.com/AdamKorcz/go-fuzz-headers-1
>> * License : Apache-2.0
>>   Programming Lang: Go
>>   Description : helper functions for Go fuzzing (library)
>>
>>  Various helper functions for go fuzzing. It is mostly used in combination
>>  with go-fuzz (https://github.com/dvyukov/go-fuzz), but compatibility with
>>  fuzzing in the standard library will also be supported. Any coverage guided
>>  fuzzing engine that provides an array or slice of bytes can be used with
>>  go-fuzz-headers.
>>  .
>>  go-fuzz-headers' approach to fuzzing structs is strongly inspired by
>>  gofuzz (https://github.com/google/gofuzz).
>>
>> I hope to maintain this package as part of Debian Go Packaging Team:
>>
>> https://salsa.debian.org/go-team/packages/golang-github-adamkorcz-go-fuzz-headers-1/
>>
>
> Usually we don't run fuzz test when building packages, because it
> would waste a lot of buildd resource.
>
> In theory we don't need any fuzz related libraries. But upstream may
> mix their unit tests and fuzz tests in one source file, which makes it
> difficult to strip such tests and their libraries.
> The Go compiler by default wouldn't run fuzz tests.
>
> For packaging rekor, I think all these fuzz tests can be stripped by
> file names. It seems upstream just puts all fuzz tests in
> "fuzz_test.go".

What is the best method to modify rekor to not need this dependency?

If rekor can work without this package, I'm happy to avoid packaging it,
although it is already in NEW.

Looking at code, it seems to be used here:

go.sum:github.com/AdamKorcz/go-fuzz-headers-1 
v0.0.0-20230618160516-e936619f9f18 
h1:rd389Q26LMy03gG4anandGFC2LW/xvjga5GezeeaxQk=
go.sum:github.com/AdamKorcz/go-fuzz-headers-1 
v0.0.0-20230618160516-e936619f9f18/go.mod 
h1:fgJuSBrJP5qZtKqaMJE0hmhS2tmRH+44IkfZvjtaf1M=
hack/tools/go.sum:github.com/AdamKorcz/go-fuzz-headers-1 
v0.0.0-2023032938-12e09aba5ebd 
h1:1tbEqR4NyQLgiod7vLXSswHteGetAVZrMGCqrJxLKRs=
hack/tools/go.sum:github.com/AdamKorcz/go-fuzz-headers-1 
v0.0.0-2023032938-12e09aba5ebd/go.mod 
h1:0vOOKsOMKPThRu9lQMAxcQ8D60f8U+wHXl07SyUw0+U=
hack/tools/tools.go:_ "github.com/AdamKorcz/go-fuzz-headers-1"
hack/tools/go.mod:  github.com/AdamKorcz/go-fuzz-headers-1 
v0.0.0-2023032938-12e09aba5ebd
pkg/types/hashedrekord/v0.0.1/fuzz_test.go: fuzz 
"github.com/AdamKorcz/go-fuzz-headers-1"
pkg/types/rpm/v0.0.1/fuzz_test.go:  fuzz 
"github.com/AdamKorcz/go-fuzz-headers-1"
pkg/types/alpine/v0.0.1/fuzz_test.go:   fuzz 
"github.com/AdamKorcz/go-fuzz-headers-1"
pkg/types/alpine/fuzz_test.go:  fuzz "github.com/AdamKorcz/go-fuzz-headers-1"
pkg/types/cose/v0.0.1/fuzz_test.go: fuzz 
"github.com/AdamKorcz/go-fuzz-headers-1"
pkg/types/jar/v0.0.1/fuzz_test.go:  fuzz 
"github.com/AdamKorcz/go-fuzz-headers-1"
pkg/types/rekord/v0.0.1/fuzz_test.go:   fuzz 
"github.com/AdamKorcz/go-fuzz-headers-1"
pkg/types/intoto/v0.0.1/fuzz_test.go:   fuzz 
"github.com/AdamKorcz/go-fuzz-headers-1"
pkg/types/intoto/v0.0.2/fuzz_test.go:   fuzz 
"github.com/AdamKorcz/go-fuzz-headers-1"
pkg/types/tuf/v0.0.1/fuzz_test.go:  fuzz 
"github.com/AdamKorcz/go-fuzz-headers-1"
pkg/types/helm/v0.0.1/fuzz_test.go: fuzz 
"github.com/AdamKorcz/go-fuzz-headers-1"
pkg/types/dsse/v0.0.1/fuzz_test.go: fuzz 
"github.com/AdamKorcz/go-fuzz-headers-1"
pkg/types/rfc3161/v0.0.1/fuzz_test.go:  fuzz 
"github.com/AdamKorcz/go-fuzz-headers-1"
pkg/fuzz/alpine_utils.go:   fuzz "github.com/AdamKorcz/go-fuzz-headers-1"
pkg/fuzz/fuzz_utils.go: fuzz "github.com/AdamKorcz/go-fuzz-headers-1"
pkg/fuzz/jar_utils.go:  fuzz "github.com/AdamKorcz/go-fuzz-headers-1"
go.mod: github.com/AdamKorcz/go-fuzz-headers-1 
v0.0.0-20230618160516-e936619f9f18

Would we have to patch all of these files?  Or disable building them
somehow?

Let's see if we can develop a workaround before ftp-master approves the
packages...  otherwise maybe it doesn't hurt to use it anyway, and may
save us time maintaining patches.

/Simon


signature.asc
Description: PGP signature

Bug#1060840: ITP: golang-k8s-sigs-release-utils -- utilities for kubernetes Go release engineering (library)

[Simon Josefsson]

Shengjing Zhu  writes:

>> https://salsa.debian.org/jas/golang-github-sigstore-rekor/-/jobs/5160982
>>
>> src/github.com/sigstore/rekor/cmd/backfill-redis/main.go:44:2:
>> cannot find package "sigs.k8s.io/release-utils/version" in any of:
>> /usr/lib/go-1.21/src/sigs.k8s.io/release-utils/version (from $GOROOT)
>> 
>> /builds/jas/golang-github-sigstore-rekor/debian/output/source_dir/_build/src/sigs.k8s.io/release-utils/version
>> (from $GOPATH)
>>
>> Use is here:
>>
>> https://github.com/sigstore/rekor/blob/main/cmd/backfill-redis/main.go#L44
>
> Hmm, then this library is needed.
>
> However I just checked the code in sigs.k8s.io/release-utils/version,
> I'm afraid it's not compatible with how we build Go binaries in
> Debian.
> We don't have any VCS info when building the binaries. And we use
> GOPATH mde as well. So the Go compiler can't inject any version info
> in the binaries.
> This code 
> https://github.com/sigstore/rekor/blob/main/cmd/backfill-redis/main.go#L103
> would probably just print "unknown, unknown"...

Can we patch rekor to not use sigs.k8s.io?  Deciding matters like that
is a bit beyond my focus right now, but very happy to discuss and take
advice (or patches) here.

That sigs.k8s.io/release-utils package needs the following dependencies
that we wouldn't have to package if we can someohow get rid of it as a
depedency for rekor.

https://salsa.debian.org/jas/golang-k8s-sigs-release-utils/-/jobs/5161034

src/sigs.k8s.io/release-utils/mage/cosign.go:24:2: cannot find package 
"github.com/uwu-tools/magex/pkg" in any of:
src/sigs.k8s.io/release-utils/version/version.go:30:2: cannot find package 
"github.com/common-nighthawk/go-figure" in any of:

/Simon


signature.asc
Description: PGP signature

Bug#1060853: ITP: golang-github-sigstore-protobuf-specs -- Sigstore Protocol Buffer code (library)

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: golang-github-sigstore-protobuf-specs
  Version : 0.2.1-1
  Upstream Author : sigstore
* URL : https://github.com/sigstore/protobuf-specs
* License : Apache-2.0
  Programming Lang: Go
  Description : Sigstore Protocol Buffer code (library)

 This repository holds protobuf specifications for Sigstore messages.

I hope to maintain this package as part of Debian Go Packaging Team:

https://salsa.debian.org/go-team/packages/golang-github-sigstore-protobuf-specs

/Simon


signature.asc
Description: PGP signature

Bug#1060852: ITP: golang-bitbucket-creachadair-shell -- implements basic shell command-line splitting for Go (library)

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: golang-bitbucket-creachadair-shell
  Version : 0.0.8-1
  Upstream Author : Michael J. Fromberger
* URL : https://bitbucket.org/creachadair/shell/
* License : BSD-3-Clause
  Programming Lang: Go
  Description : implements basic shell command-line splitting for Go 
(library)

 Provides supports for splitting and joining of shell command strings.
 .
 The Split function divides a string into whitespace-separated fields,
 respecting single and double quotation marks as defined by the Shell Command
 Language section of IEEE Std 1003.1 2013.  The Quote function quotes
 characters that would otherwise be subject to shell evaluation, and the Join
 function concatenates quoted strings with spaces between them.

I hope to maintain this package as part of Debian Go Packaging Team:

https://salsa.debian.org/go-team/packages/golang-bitbucket-creachadair-shell/

/Simon


signature.asc
Description: PGP signature

Bug#1060840: ITP: golang-k8s-sigs-release-utils -- utilities for kubernetes Go release engineering (library)

[Simon Josefsson]

Shengjing Zhu  writes:

> On Mon, Jan 15, 2024 at 9:27 PM Simon Josefsson  wrote:
>>
>> Package: wnpp
>> Severity: wishlist
>> Owner: Simon Josefsson 
>>
>> * Package name: golang-k8s-sigs-release-utils
>>   Version : 0.7.7-1
>>   Upstream Author : Kubernetes SIGs
>> * URL : https://github.com/kubernetes-sigs/release-utils
>> * License : Apache-2.0
>>   Programming Lang: Go
>>   Description : utilities for kubernetes Go release engineering (library)
>>
>>  Tiny utilities for use by the Release Engineering subproject and
>>  kubernetes/release (https://github.com/kubernetes/release/).
>>
>
> Which package will need this library? It looks strange by the name and
> description. We certainly don't do the release stuff for kubernetes.

Sigstore's rekor complained:

https://salsa.debian.org/jas/golang-github-sigstore-rekor/-/jobs/5160982

src/github.com/sigstore/rekor/cmd/backfill-redis/main.go:44:2: cannot find 
package "sigs.k8s.io/release-utils/version" in any of:
/usr/lib/go-1.21/src/sigs.k8s.io/release-utils/version (from $GOROOT)

/builds/jas/golang-github-sigstore-rekor/debian/output/source_dir/_build/src/sigs.k8s.io/release-utils/version
 (from $GOPATH)

Use is here:

https://github.com/sigstore/rekor/blob/main/cmd/backfill-redis/main.go#L44

Can you think of some other solution than packaging
golang-k8s-sigs-release-utils?  I would be happy to learn about
alternative approaches to reduce golang dependencies.

/Simon


signature.asc
Description: PGP signature

Bug#1060842: ITP: trillian -- A transparent, highly scalable and cryptographically verifiable data store

[Simon Josefsson]

Alexandre Detiste  writes:

> People using the non-free trillian.deb (the chat client)
> will have a nasty surprise
>
> https://forums.debian.net/viewtopic.php?t=146679

Ouch, good catch, this needs some planning.  However it is not packaged
in Debian nor are there any signs of it inside the official Debian as
far as I can tell.

My primary use-case is the trillian golang libraries, for sigstore's
rekor.  I'll see about starting with them only.  The 'trillian' binary
package can be added later, under that name or another.

/Simon

> Le lun. 15 janv. 2024 à 15:03, Simon Josefsson  a écrit :
>>
>> Package: wnpp
>> Severity: wishlist
>> Owner: Simon Josefsson 
>>
>> * Package name: trillian


signature.asc
Description: PGP signature

Bug#1060842: ITP: trillian -- A transparent, highly scalable and cryptographically verifiable data store

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: trillian
  Version : 1.6.0-1
  Upstream Author : Google
* URL : https://github.com/google/trillian
* License : Apache-2.0
  Programming Lang: Go
  Description : A transparent, highly scalable and cryptographically 
verifiable data store

 Trillian is an implementation of the concepts described in the
 Verifiable Data Structures (/docs/papers/VerifiableDataStructures.pdf)
 white paper, which in turn is an extension and generalisation of the
 ideas which underpin Certificate Transparency (https://certificate-
 transparency.org).
 .
 Trillian implements a Merkle tree
 (https://en.wikipedia.org/wiki/Merkle_tree) whose contents are served
 from a data storage layer, to allow scalability to extremely large
 trees.  On top of this Merkle tree, Trillian provides the following:
 .
  * An append-only **Log** mode, analogous to the original
Certificate Transparency (https://certificate-transparency.org) logs.
In
this mode, the Merkle tree is effectively filled up from the left,
giving a
*dense* Merkle tree.
 .
 Certificate Transparency (CT) (https://tools.ietf.org/html/rfc6962) is
 the most well-known and widely deployed transparency application, and an
 implementation of CT as a Trillian personality is available in the
 certificate-transparency-go repo (https://github.com/google/certificate-
 transparency-go/blob/master/trillian).

I hope to maintain this package as part of Debian Go Packaging Team:

https://salsa.debian.org/go-team/packages/trillian

/Simon


signature.asc
Description: PGP signature

Bug#1060841: ITP: golang-github-transparency-dev-merkle -- create and manipulate Merkle trees in Go (library)

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: golang-github-transparency-dev-merkle
  Version : 0.0.2-1
  Upstream Author : Pavel Kalinnikov, Al Cutter, Martin Hutchinson, M Hickford, 
et al
* URL : https://github.com/transparency-dev/merkle
* License : Apache-2.0
  Programming Lang: Go
  Description : create and manipulate Merkle trees in Go (library)

 Provides Go code to help create and manipulate Merkle trees, as well as
 constructing and verifying various types of proof.
 .
 This is the data structure which is used by projects such as Trillian
 (https://github.com/google/trillian) to provide verifiable logs
 (https://transparency.dev/verifiable-data-structures/#verifiable-log).

I hope to maintain this package as part of Debian Go Packaging Team:

https://salsa.debian.org/go-team/packages/golang-github-transparency-dev-merkle

/Simon


signature.asc
Description: PGP signature

Bug#1060840: ITP: golang-k8s-sigs-release-utils -- utilities for kubernetes Go release engineering (library)

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: golang-k8s-sigs-release-utils
  Version : 0.7.7-1
  Upstream Author : Kubernetes SIGs
* URL : https://github.com/kubernetes-sigs/release-utils
* License : Apache-2.0
  Programming Lang: Go
  Description : utilities for kubernetes Go release engineering (library)

 Tiny utilities for use by the Release Engineering subproject and
 kubernetes/release (https://github.com/kubernetes/release/).

I hope to maintain this package as part of Debian Go Packaging Team:

https://salsa.debian.org/go-team/packages/golang-k8s-sigs-release-utils

/Simon


signature.asc
Description: PGP signature

Bug#1060839: ITP: golang-github-adamkorcz-go-fuzz-headers-1 -- helper functions for Go fuzzing (library)

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: golang-github-adamkorcz-go-fuzz-headers-1
  Version : 0.0~git20230919.8b5d3ce-1
  Upstream Author : Adam Korcz 
* URL : https://github.com/AdamKorcz/go-fuzz-headers-1
* License : Apache-2.0
  Programming Lang: Go
  Description : helper functions for Go fuzzing (library)

 Various helper functions for go fuzzing. It is mostly used in combination
 with go-fuzz (https://github.com/dvyukov/go-fuzz), but compatibility with
 fuzzing in the standard library will also be supported. Any coverage guided
 fuzzing engine that provides an array or slice of bytes can be used with
 go-fuzz-headers.
 .
 go-fuzz-headers' approach to fuzzing structs is strongly inspired by
 gofuzz (https://github.com/google/gofuzz).

I hope to maintain this package as part of Debian Go Packaging Team:

https://salsa.debian.org/go-team/packages/golang-github-adamkorcz-go-fuzz-headers-1/

/Simon


signature.asc
Description: PGP signature

Bug#1060836: ITP: golang-github-cavaliergopher-rpm -- A Go implementation of the RPM file format

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: golang-github-cavaliergopher-rpm
  Version : 1.2.0-1
  Upstream Author : Ryan Armstrong, et al
* URL : https://github.com/cavaliergopher/rpm
* License : BSD-3-clause
  Programming Lang: Go
  Description : Go implementation of the RPM file format (library)

 This implements the rpm package file format as a Go library
 .
 See the package documentation
 (https://pkg.go.dev/github.com/cavaliergopher/rpm) to get started.

I hope to maintain this package as part of Debian Go Packaging Team:

https://salsa.debian.org/go-team/packages/golang-github-cavaliergopher-rpm

/Simon


signature.asc
Description: PGP signature

Bug#1060834: ITP: golang-github-veraison-go-cose -- go library for CBOR Object Signing and Encryption (COSE)

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: golang-github-veraison-go-cose
  Version : 1.2.1-1
  Upstream Author : Veraison
* URL : https://github.com/veraison/go-cose
* License : MPL-2.0
  Programming Lang: Go
  Description : go library for CBOR Object Signing and Encryption (COSE)

 A golang library for the COSE specification
 (https://datatracker.ietf.org/doc/rfc9052/)

I hope to maintain this package as part of Debian Go Packaging Team:

https://salsa.debian.org/go-team/packages/golang-github-veraison-go-cose

/Simon


signature.asc
Description: PGP signature

Bug#1060820: ITP: golang-github-cyberphone-json-canonicalization -- JSON Canonicalization Scheme (JCS) (Go library)

[Simon Josefsson]

Reinhard Tartler  writes:

> On Sun, Jan 14, 2024 at 8:36 PM Simon Josefsson  wrote:
>
>> Package: wnpp
>> Severity: wishlist
>> Owner: Simon Josefsson 
>>
>> * Package name: golang-github-cyberphone-json-canonicalization
>>   Version : 0.0~git20220623.57a0ce2-1
>>   Upstream Author : Anders Rundgren
>> * URL : https://github.com/cyberphone/json-canonicalization
>> * License : Apache-2.0
>>   Programming Lang: Go
>>   Description : JSON Canonicalization Scheme (JCS) (Go library)
>>
>>
> I contemplated packaging this library in the past, but found it actually
> contains
> a lot of other stuff I didn't nede. In the end, I ended up packaging
> https://salsa.debian.org/debian/golang-webpki-org-jsoncanonicalizer
> which seems to be what the proposed package is "repackaing".
>
> In a way, I went straight for the source, I guess.

Thanks -- I missed your package!  No ITP bug?

Your package looks cleaner, and I haven't yet figured out how to repack
the golang-github-cyberphone-json-canonicalization tarball to only
contain the Go code, much in the same way you did but instead extracted
only the source code.  I am considering to use your package instead, and
haven't made the ftp-master NEW upload yet for 1060820.

I wasn't able to build your package, did you forgot to push upstream
branch and tags?

Rekor has github.com/cyberphone/json-canonicalization in go.mod and is
using that namespace:

jas@kaka:~/dpkg/golang-github-sigstore-rekor$ rgrep jsoncanonicalizer .
./tests/e2e_test.go:
"github.com/cyberphone/json-canonicalization/go/src/webpki.org/jsoncanonicalizer"
./tests/e2e_test.go:canonicalized, err := 
jsoncanonicalizer.Transform(payload)
./pkg/verify/verify.go: 
"github.com/cyberphone/json-canonicalization/go/src/webpki.org/jsoncanonicalizer"
./pkg/verify/verify.go: canonicalized, err := 
jsoncanonicalizer.Transform(contents)
./pkg/types/entries.go: 
"github.com/cyberphone/json-canonicalization/go/src/webpki.org/jsoncanonicalizer"
./pkg/types/entries.go: return jsoncanonicalizer.Transform(canonicalEntry)
./pkg/api/entries.go:   
"github.com/cyberphone/json-canonicalization/go/src/webpki.org/jsoncanonicalizer"
./pkg/api/entries.go:   canonicalized, err := 
jsoncanonicalizer.Transform(payload)
./pkg/pki/tuf/tuf.go:   
"github.com/cyberphone/json-canonicalization/go/src/webpki.org/jsoncanonicalizer"
./pkg/pki/tuf/tuf.go:   return jsoncanonicalizer.Transform(marshalledBytes)
./pkg/pki/tuf/tuf.go:   return jsoncanonicalizer.Transform(marshalledBytes)
jas@kaka:~/dpkg/golang-github-sigstore-rekor$ 

How would I force it to use your webpki.org namespace instead, simply
patch all these occurances?  Is is acceptable to patch upstream Go code
to use other dependencies for Debian?  I haven't done this with any
package, so some assistance is appreciated.  For reference my rekor
package lives here:

https://salsa.debian.org/jas/golang-github-sigstore-rekor

Is this approach really scalable?  Say 100 other upstream projects end
up using cyberphone namespace, then Debian has to carry patches to
change namespace for all of them, which is a lot of manual work.

Once I can build your package, I can experiment with using it instead of
my variant that lives here (failing license and lintian checks):

https://salsa.debian.org/go-team/packages/golang-github-cyberphone-json-canonicalization
https://salsa.debian.org/jas/golang-github-cyberphone-json-canonicalization/-/pipelines

Hmm.  Thinking out loud, perhaps a simpler compromise is to use your
packaging but use the upstream namespace instead of changing it to
golang-webpki-org-jsoncanonicalizer and webpki.org/jsoncanonicalizer
namespace?  Then no dependency will require patches.

/Simon


signature.asc
Description: PGP signature

Bug#1060820: ITP: golang-github-cyberphone-json-canonicalization -- JSON Canonicalization Scheme (JCS) (Go library)

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: golang-github-cyberphone-json-canonicalization
  Version : 0.0~git20220623.57a0ce2-1
  Upstream Author : Anders Rundgren
* URL : https://github.com/cyberphone/json-canonicalization
* License : Apache-2.0
  Programming Lang: Go
  Description : JSON Canonicalization Scheme (JCS) (Go library)

 Cryptographic operations like hashing and signing depend on that the
 target data does not change during serialization, transport, or parsing.
 By applying the rules defined by JCS (JSON Canonicalization Scheme),
 data provided in the JSON [RFC8259
 (https://tools.ietf.org/html/rfc8259)] format can be exchanged "as is",
 while still being subject to secure cryptographic operations. JCS
 achieves this by building on the serialization formats for JSON
 primitives as defined by ECMAScript [ES (https://ecma-
 international.org/ecma-262/)], constraining JSON data to the I-JSON
 [RFC7493 (https://tools.ietf.org/html//rfc7493)] subset, and through a
 platform independent property sorting scheme.
 .
 Public RFC: (https://tools.ietf.org/html/rfc8785)
 .
 The JSON Canonicalization Scheme concept in a nutshell:
 .
  * Serialization of primitive JSON data types using methods compatible
with ECMAScript's JSON.stringify()
  * Lexicographic sorting of JSON Object properties in a *recursive*
process
  * JSON Array data is also subject to canonicalization, *but element
order remains untouched*

I hope to maintain this package as part of Debian Go Packaging Team:

https://salsa.debian.org/go-team/packages/golang-github-cyberphone-json-canonicalization

/Simon


signature.asc
Description: PGP signature

Bug#1060819: ITP: golang-github-zeebo-errs -- errs is a package for making errors friendly and easy

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: golang-github-zeebo-errs
  Version : 1.3.0-1
  Upstream Author : Jeff Wendling
* URL : https://github.com/zeebo/errs
* License : Expat
  Programming Lang: Go
  Description : errs is a Go library for making errors friendly and easy

 errs is a package for making errors friendly and easy.  Errors come
 with a stack trace that is only printed when a "+" character is used in
 the format string. This should retain the benefits of being able to
 diagnose where and why errors happen, without all of the noise of
 printing a stack trace in every situation.

I hope to maintain this package as part of Debian Go Packaging Team:

https://salsa.debian.org/go-team/packages/golang-github-zeebo-errs/

/Simon


signature.asc
Description: PGP signature

Bug#1060818: ITP: in-toto-golang -- framework for software supply chain integrity

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: in-toto-golang
  Version : 0.9.0-1
  Upstream Author : Aditya Sirish, Christian Rebischke, Lukas Pühringer, et al
* URL : https://github.com/in-toto/in-toto-golang
* License : Apache-2.0
  Programming Lang: Go
  Description : framework for software supply chain integrity

 Go implementation of in-toto

I hope to maintain this package as part of Debian Go Packaging Team:

https://salsa.debian.org/go-team/packages/in-toto-golang/

/Simon



signature.asc
Description: PGP signature

Bug#1060817: ITP: golang-github-spiffe-go-spiffe -- Golang library for SPIFFE support

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: golang-github-spiffe-go-spiffe
  Version : 2.1.6-1
  Upstream Author : Agustín Martínez Fayó, Andrew Harding, et al
* URL : https://github.com/spiffe/go-spiffe
* License : Apache-2.0
  Programming Lang: Go
  Description : Golang library for SPIFFE support

 This library is a convenient Go library for working with SPIFFE
 (https://spiffe.io/).
 .
 It leverages the SPIFFE Workload API
 (https://github.com/spiffe/spiffe/blob/main/standards/SPIFFE_Workload_API.md),
 providing high level functionality that includes:
 .
  * Establishing mutually authenticated TLS (**mTLS**) between workloads
powered by SPIFFE.
  * Obtaining and validating X509-SVIDs
(https://github.com/spiffe/spiffe/blob/main/standards/X509-SVID.md) and
JWT-SVIDs (https://github.com/spiffe/spiffe/blob/main/standards/JWT-
SVID.md).
  * Federating trust between trust domains using SPIFFE bundles

(https://github.com/spiffe/spiffe/blob/main/standards/SPIFFE_Trust_Domain_and_Bundle.md#3-
spiffe-bundles).
  * Bundle management.

I hope to maintain this package as part of Debian Go Packaging Team:

https://salsa.debian.org/go-team/packages/golang-github-spiffe-go-spiffe/

/Simon


signature.asc
Description: PGP signature

Bug#1060816: ITP: golang-github-shibumi-go-pathspec -- gitignore-style pathspec pattern matching in Go

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: golang-github-shibumi-go-pathspec
  Version : 1.3.0-1
  Upstream Author : Sander van Harmelen, Christian Rebischke
* URL : https://github.com/shibumi/go-pathspec
* License : Apache-2.0
  Programming Lang: Go
  Description : gitignore-style pathspec pattern matching in Go

 go-pathspec implements gitignore-style pattern matching for paths.

I hope to maintain this package as part of Debian Go Packaging Team:

https://salsa.debian.org/go-team/packages/golang-github-shibumi-go-pathspec/

/Simon


signature.asc
Description: PGP signature

Bug#1060815: ITP: relic -- digitally sign Linux/Java/Windows packages

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: relic
  Version : 7.6.1-1
  Upstream Author : SAS Institute, Inc.
* URL : https://github.com/sassoftware/relic
* License : Apache-2.0
  Programming Lang: Go
  Description : digitally sign Linux/Java/Windows packages

 relic is a multi-tool and server for package signing and working with
 hardware security modules (HSMs).
 .
 Package types
 .
  * RPM - RedHat packages
  * DEB - Debian packages
  * JAR - Java archives
  * EXE (PE/COFF) - Windows executable
  * MSI - Windows installer
  * appx, appxbundle - Windows universal application
  * CAB - Windows cabinet file
  * CAT - Windows security catalog
  * XAP - Silverlight and legacy Windows Phone applications
  * PS1, PS1XML, MOF, etc. - Microsoft Powershell scripts and modules
  * manifest, application - Microsoft ClickOnce manifest
  * VSIX - Visual Studio extension
  * Mach-O - macOS/iOS signed executables
  * DMG, PKG - macOS disk images / installer packages
  * APK - Android package
  * PGP - inline, detached or cleartext signature of data
 .
 Token types
 .
 relic can work with several types of token:
 .
  * pkcs11 - Industry standard PKCS#11 HSM interface using shared object
files
  * Cloud services - AWS, Azure and Google Cloud managed keys
  * scdaemon - The GnuPG scdaemon service can enable access to OpenPGP
cards (such as Yubikey NEO)
  * file - Private keys stored in a password-protected file
 .
 Features
 .
 Relic is primarily meant to operate as a signing server, allowing
 clients to authenticate with a TLS certificate and sign packages
 remotely. It can also be used as a standalone signing tool.
 .
 Other features include:
 .
  * Generating and importing keys in the token
  * Importing certificate chains from a PKCS#12 file
  * Creating X509 certificate signing requests (CSR) and self-signed
certificates
  * Limited X509 CA support -- signing CSRs and cross-signing certificates
  * Creating simple PGP public keys
  * RSA and ECDSA supported for all signature types
  * Verify signatures, certificate chains and timestamps on all supported
package types
  * Sending audit logs to an AMQP broker, with an optional sealing
signature
  * Save token PINs in the system keyring
 .
 Linux, Windows and MacOS are supported. Other platforms probably work as
 well.
 .
 relic is tested using libsofthsm2 and Gemalto SafeNet Network HSM (Luna
 SA).

I hope to maintain this package as part of Debian Go Packaging Team:

https://salsa.debian.org/go-team/packages/relic

/Simon


signature.asc
Description: PGP signature

Bug#1060813: ITP: golang-github-qur-ar -- Golang ar archive file library

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: golang-github-qur-ar
  Version : 0.0~git20130629.282534b-1
  Upstream Author : Blake Smith, Julian Phillips
* URL : https://github.com/qur/ar
* License : Expat
  Programming Lang: Go
  Description : Golang ar archive file library

 Golang ar (archive) file reader
 .
 This is a simple library for reading and writing ar
 (http://en.wikipedia.org/wiki/Ar_(Unix)) files in common format. It is
 influenced heavily in style and interface from the golang tar
 (http://golang.org/pkg/archive/tar/) package.

I hope to maintain this package as part of Debian Go Packaging Team:

https://salsa.debian.org/go-team/packages/golang-github-qur-ar

/Simon


signature.asc
Description: PGP signature

Bug#1060810: ITP: golang-github-sassoftware-go-rpmutils -- Golang implementation of parsing RPM packages

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: golang-github-sassoftware-go-rpmutils
  Version : 0.2.0-1
  Upstream Author : SAS Institute, Inc.
* URL : https://github.com/sassoftware/go-rpmutils
* License : Apache-2.0
  Programming Lang: Go
  Description : Golang implementation of parsing RPM packages

 go-rpmutils is a library written in go (http://golang.org) for parsing
 and extracting content from RPMs (http://www.rpm.org).
 .
 go-rpmutils provides a few interfaces for handling RPM packages. There is
 a highlevel Rpm struct that provides access to the RPM header and CPIO
 (https://en.wikipedia.org/wiki/Cpio) payload. The CPIO payload can be
 extracted to a filesystem location via the ExpandPayload function or
 through a Reader interface, similar to the tar implementation
 (https://golang.org/pkg/archive/tar/) in the go standard library.

I hope to maintain this package as part of Debian Go Packaging Team:

https://salsa.debian.org/go-team/packages/golang-github-sassoftware-go-rpmutils

/Simon


signature.asc
Description: PGP signature

Bug#1050314: Sigstore rekor in Debian

[Simon Josefsson]

Hi

Just a heads-up that I am working on packaging rekor for Debian, current
effort is under way here:

https://salsa.debian.org/jas/golang-github-sigstore-rekor

I will merge it here eventually:

https://salsa.debian.org/go-team/packages/golang-github-sigstore-rekor

It seems like a great number of dependencies are needed, and I'm
chaising them down one by one, although for several it raises new
problems since Debian has old versions of the package and it isn't clear
to me wheter to update the old packages are create new packages for
them, especially since some of them have been renamed so the golang
package names no longer match.

I'm cc'ing both bugs related to this, I think they refer to the same
package really.

/Simon


signature.asc
Description: PGP signature

Bug#1059618: ITP: ssh3 -- faster and rich secure shell using HTTP/3

[Simon Josefsson]

Colin Watson  writes:

> On Sat, Dec 30, 2023 at 12:13:28AM +0100, Philipp Kern wrote:
>> On 29.12.23 11:30, Simon Josefsson wrote:
>> > SSH3 is a complete revisit of the SSH protocol, mapping its semantics on
>> > top of the HTTP mechanisms. In a nutshell, SSH3 uses QUIC+TLS1.3 for
>> > secure channel establishment and the HTTP Authorization mechanisms for
>> > user authentication. Among others, SSH3 allows the following
>> > improvements:
>> 
>> I feel like SSH3 is an unfortunate name. The program claims "SSH3 stands for
>> the concatenation of SSH and H3." - well sure, but you're also reusing the
>> name of an existing protocol and bump its version. ssh-h3?
>
> I agree - as the Debian OpenSSH maintainer, I'm concerned that this will
> cause a new source of user confusion because people will think "ah,
> ssh3, that must be better than ssh" (which indeed seems to have been a
> deliberate marketing choice by this project) and not realize that it's a
> largely incompatible thing.  Not to mention the way that it parses
> OpenSSH configuration files, which may work today but I doubt OpenSSH
> offers any guarantees that it won't make changes that will break this
> independent parser in future.

I share these concerns, so I'll delay the upload for now.  I'm hoping
upstream will rename the project to something less confusing.

> I also feel that something security-critical like this that's labelled
> by upstream as "still experimental" probably shouldn't be in a Debian
> release.  Maybe it should be kept in Debian experimental for the time
> being?

Sounds good if nothing happens on the naming front in the next
weeks/months.  Let's wait and see a bit.

One alternative that was suggested was to call the package something
else in Debian.  'golang-ssh3'?  'go-ssh3'?  Still somewhat problematic
as long as the 'ssh3' name is in there.

/Simon


signature.asc
Description: PGP signature

Bug#1059618: ITP: ssh3 -- faster and rich secure shell using HTTP/3

[Simon Josefsson]

Packaging of SSH3 is available here:

https://salsa.debian.org/go-team/packages/ssh3
https://salsa.debian.org/jas/ssh3/

Thanks to the Salsa CI/CD pipeline there is an aptly repository
available for easy testing, if anyone would like to experiment or help.

Below you can find a snippet how you can test the SSH3 client and server
via Debian packages, for password and public key authentication, in a
safe container using podman.  I have only tested this on my laptop that
runs Trisquel, but should hopefully be portable.

I am delaying upload to Debian for a while to see if upstream reaches a
conclusion around naming.  I think the name 'ssh3' is unfortunate and
distracts from the effort. See:
.

/Simon

sudo apt install podman
podman run -it --hostname myhost.example --rm debian:unstable
cd
apt update
apt dist-upgrade -y
apt install -y ca-certificates
echo "deb [trusted=yes] 
https://salsa.debian.org/jas/ssh3/-/jobs/5094673/artifacts/raw/aptly unstable 
main" | tee /etc/apt/sources.list.d/ssh3.list
apt update
apt install -y ssh3

apt install -y ssl-cert # creates snakeoil key/cert

passwd # set a test password for 'root' e.g. 'foo'

ssh3-server -cert /etc/ssl/certs/ssl-cert-snakeoil.pem -key 
/etc/ssl/private/ssl-cert-snakeoil.key -enable-password-login -url-path /myurl 
-v &

ssh3 -v -insecure -use-password myhost.example/myurl
# type 'foo' at the prompt, and on successful connection type 'exit' to log out

apt install -y openssh-client # for ssh-keygen
ssh-keygen -t ed25519 -P "" -f /root/.ssh/id_ed25519
cat /root/.ssh/id_ed25519.pub > /root/.ssh3/authorized_identities
ssh3 -v -insecure -privkey /root/.ssh/id_ed25519 myhost.example/myurl
# on successful connection type 'exit' to log out


signature.asc
Description: PGP signature

Bug#1059620: ITP: golang-github-golang-jwt-jwt-v5 -- golang implementation of JSON Web Tokens (library)

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org

* Package name: golang-github-golang-jwt-jwt-v5
  Version : 5.2.0-1
  Upstream Author : golang-jwt maintainers, Dave Grijalva
* URL : https://github.com/golang-jwt/jwt
* License : Expat
  Programming Lang: Go
  Description : golang implementation of JSON Web Tokens (library)

I have working packaging of this here:

https://salsa.debian.org/jas/jwt-v5/

I hope to maintain it in the Debian Go Packaging group eventually.

This package appears to be required by the 'ssh3' package, and the
existing golang-github-golang-jwt-jwt package is stuck on the old ABI
and it looks like it will never upgrade, see:
https://tracker.debian.org/pkg/golang-github-golang-jwt-jwt

/Simon


signature.asc
Description: PGP signature

Bug#1059618: ITP: ssh3 -- faster and rich secure shell using HTTP/3

[Simon Josefsson]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-de...@lists.debian.org, debian...@lists.debian.org

* Package name: ssh3
  Version : 0.1.4
  Upstream Contact: François Michel
* URL : https://github.com/francoismichel/ssh3
* License : Apache-2.0
  Programming Lang: Go
  Description : faster and rich secure shell using HTTP/3

SSH3 is a complete revisit of the SSH protocol, mapping its semantics on
top of the HTTP mechanisms. In a nutshell, SSH3 uses QUIC+TLS1.3 for
secure channel establishment and the HTTP Authorization mechanisms for
user authentication. Among others, SSH3 allows the following
improvements:

- Significantly faster session establishment

- New HTTP authentication methods such as OAuth 2.0 and OpenID Connect
  in addition to classical SSH authentication

- Robustness to port scanning attacks: your SSH3 server can be made
  invisible to other Internet users

- UDP port forwarding in addition to classical TCP port forwarding

- All the features allowed by the modern QUIC protocol: including
  connection migration (soon) and multipath connections

I hope this package can be maintained in the Debian Go Packaging Team.


signature.asc
Description: PGP signature

Bug#1059267: ITP: apt-verify - extend apt's gpgv-based verification mechanism

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: si...@josefsson.org
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: apt-verify
  Version : 2.0
  Upstream Contact: Simon Josefsson 
* URL : https://gitlab.com/debdistutils/apt-verify
* License : AGPLv3+
  Programming Lang: Shell script
  Description : extend apt's gpgv-based verification mechanism

Apt-verify extends apt to call all tools in /etc/verify.d/ instead of
always only calling gpgv, to verify apt archive integrity and
authenticity.  A symbolic link in /etc/verify.d/gpgv is installed by
default to provide full backwards compatibility.

/Simon


signature.asc
Description: PGP signature

Bug#1055615: RFP: system76-ectool -- System76 Open Source Embedded Controller tool

[Simon Josefsson]

Package: wnpp
Severity: wishlist

* Package name: system76-ectool
  Upstream Author : System76 / Jeremy Soller
* URL : https://github.com/system76/ec
* License : MIT
  Programming Lang: Rust
  Description : firmware tool for System76 Open Source Embedded Controller

The system76_ectool is used to interact with the System76 Open Source
Embedded Controller firmware.  The firmware can be used on laptops
from several vendors including System76, Clevo, NovaCustom, etc.

I tried to package it, but I don't know rust.  Following the packaging
tutorial ended when it depended on the hidapi-1 crate, where Debian only
has hidapi-2.  I opened an upstream bug about upgrading to hidapi 2 at
https://github.com/system76/ec/issues/419 and I also tried to package
hidapi-1 but I never managed to get it to build due to some
libusb-related problem.  I'm sure someone with more rust packaging
skills could work this out more easily, and I'm happy to test resulting
binaries since my laptop has this EC firwmare.

/Simon


signature.asc
Description: PGP signature

Bug#1053568: ITP: python-lib25519 -- Python wrapper around lib25519 library

[Simon Josefsson]

Hi.  I'm happy to review, co-maintain and sponsor this package.  Initial
review:

- Could you add debian/tests/ infrastructure?

- It installs a "top_level.txt" file, is this intentional?  Lintian
complaint:
I: python3-lib25519: package-contains-documentation-outside-usr-share-doc 
[usr/lib/python3/dist-packages/lib25519-20230630.1.dist-info/top_level.txt]

/Simon


signature.asc
Description: PGP signature

Bug#1053569: ITP: python-mceliece -- Python wrapper around libmceliece library

[Simon Josefsson]

Hi.  I'm happy to review, co-maintain and sponsor this package.  Initial
review:

- Could you add debian/tests/ infrastructure?

- It installs a "top_level.txt" file, is this intentional?  Lintian
complaint: I: python3-mceliece:
package-contains-documentation-outside-usr-share-doc
[usr/lib/python3/dist-packages/mceliece-20230612.1.dist-info/top_level.txt]

/Simon


signature.asc
Description: PGP signature

Bug#1050531: ITP: libmceliece -- Classic McEliece microlibrary

[Simon Josefsson]

Hi.  I'm happy to rewview, sponsor and co-maintain this package.  I
created https://salsa.debian.org/debian/libmceliece as a hopefully
better place to maintian the package in?

I did a review of the package and it looks fine, and I'm ready to upload
it.  Do you have any other changes pending?

/Simon


signature.asc
Description: PGP signature

Bug#656665: ITP: libglobalplatform -- library to handle communication with GlobalPlatform cards

[Simon Josefsson]

retitle 656665 ITP: globalplatform -- library to handle communication with 
GlobalPlatform cards
owner 656665 Simon Josefsson 
tag 656665 + pending
thanks

Hi.

I have discovered that upstream is active again, and have made releases
in recent years:

https://github.com/kaoh/globalplatform

That projects merges all three of the earlier globalplatform, gpshell,
and gppcscconnectionplugin projects.  Now only one Debian source
packages would be necessary for the three earlier upstream projects.
Thus I think #656959 and #656957 could be closed once #656665 is fixed
with an upload of the new merged package.

For references, here are my earlier packaging effort which was never
uploaded into Debian but only used locally:

https://github.com/Yubico/globalplatform-dpkg
https://github.com/Yubico/gpshell-dpkg
https://github.com/Yubico/gppcscconnectionplugin-dpkg

The following is where I experiment with new packaging, it is work in
progress:

https://salsa.debian.org/auth-team/globalplatform

/Simon


signature.asc
Description: PGP signature

Bug#1051553: ITP: lib25519 -- X25519/Ed25519 microlibrary

[Simon Josefsson]

tor 2023-09-14 klockan 11:10 +0200 skrev Jan Mojzis:
> > I would be happy to help review, co-maintain and upload this
> > package.
> 
> Great, thank You.
> 
> 
> First prototype for review:
> 'https://salsa.debian.org/janmojzis/lib25519'
> 
> if it's ok
> can you please create 'salsa.debian.org/debian/lib25519',
> I will move it there.

Great!

I have created it -- can you push everything there, and I will do a
review via a merge request to that repository?

/Simon

> 
> Currently without autopkgtest,
> I will add it when librandombytes package  arrives in unstable.
> 
> 
> Thanks
> Jan
> 



signature.asc
Description: This is a digitally signed message part

Bug#1051553: ITP: lib25519 -- X25519/Ed25519 microlibrary

[Simon Josefsson]

Jan Mojzis  writes:

> * Package name: lix25519
^ lib25519 I guess?

Otherwise looks good to me.

> I'm using this library and I'm going to maintain using 
> https://salsa.debian.org/
> I need sponsor for the first upload (I'm DM).

I would be happy to help review, co-maintain and upload this package.

/Simon


signature.asc
Description: PGP signature

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

[Simon Josefsson]

Sam Hartman  writes:

>> "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.

We have plenty of code written under that same license from the same
group of authors, already in Debian.  Look in OpenSSH and OpenSSL for
example.  So I would disagree there is a license problem having this
package in Debian.

Jan, I'm happy to help review, sponsor and co-maintain randombytes if
you are interested.  I rely on it as a dependency in some projects I'm
working on.

/Simon


signature.asc
Description: PGP signature

Bug#1042827: [Pkg-sssd-devel] priv-wrapper?

[Simon Josefsson]

Timo Aaltonen  writes:

> Simon Josefsson kirjoitti 1.8.2023 klo 18.46:
>> Hi
>> I have finished packaging cwrap's priv-wrapper:
>> https://salsa.debian.org/jas/priv-wrapper/
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042827
>> Would you be interested in co-maintaining priv-wrapper in the SSSD
>> group?  I noticed that SSSD maintains some of the other cwrap projects:
>> https://tracker.debian.org/pkg/nss-wrapper
>> https://tracker.debian.org/pkg/pam-wrapper
>> https://tracker.debian.org/pkg/uid-wrapper
>> I'm happy to maintain priv-wrapper in the sssd-group, and help
>> improve
>> packaging of other SSSD packages (e.g, upload new releases), if you
>> grant me access to the Salsa gitlab group.
>> /Simon
>
> Hi,
>
> That sounds fine.

Great -- I'll move priv-wrapper once ftp-master has approved it, and
then make a new upload using its new home.

I'll review nss/pam/uid-wrapper next, I don't expect much changes, I'll
upload to DELAYED to allow for review.

> I had a brief look at priv-wrapper packaging, and noticed it only
> keeps the debian/ dir in git? The sssd-team packages have the full
> upstream git as the base, with packaging added to the packaging
> branch. I prefer those will remain like that :)

I usually also do the full git repo with upstream branch for most of the
packages I maintain, but for this new package I wanted to see if keeping
only debian/ in git worked, as I've had success with that in another
package.  What is really the upside of having upstream code in Debian's
git?  One downside is that it wastes space, although I don't think that
matters a lot these days.  Another downside is that it confuses what is
really the "upstream" in case the Debian git-repo's view of what
"upstream" is differs from the real upstream.

Just to clarify, did you mean that you would want priv-wrapper to use
the same style as the other packages, or merely that I shouldn't change
the other sssd-packages to use this debian/-only approach?  I wouldn't
do the latter.  Generally if you feel there is any subjective style
matter you don't agree with, I'm happy to follow what you prefer.  I
prefer to keep priv-wrapper as debian/-only if you think that is okay,
unless I learn some disadvantage with it that I am not aware of yet.

/Simon

PS. Changing to your ubuntu.com email address since sending to your
debian.org address results in bounces when debian.org forwards it to
ubuntu.com because debian.org is not authorized to send emails on behalf
of si...@josefsson.org due to (probably) my SPF 'mx -all' preference.  I
think it is a problem with the debian.org forwarder..


signature.asc
Description: PGP signature

Bug#1042827: priv-wrapper?

[Simon Josefsson]

Hi

I have finished packaging cwrap's priv-wrapper:

https://salsa.debian.org/jas/priv-wrapper/
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042827

Would you be interested in co-maintaining priv-wrapper in the SSSD
group?  I noticed that SSSD maintains some of the other cwrap projects:

https://tracker.debian.org/pkg/nss-wrapper
https://tracker.debian.org/pkg/pam-wrapper
https://tracker.debian.org/pkg/uid-wrapper

I'm happy to maintain priv-wrapper in the sssd-group, and help improve
packaging of other SSSD packages (e.g, upload new releases), if you
grant me access to the Salsa gitlab group.

/Simon


signature.asc
Description: PGP signature

Bug#1042827: ITP: priv-wrapper -- library to disable resource limits and other privilege dropping

[Simon Josefsson]

Package: wnpp
Severity: wishlist

Hi!  I am planning to package priv-wrapper:

   https://cwrap.org/priv_wrapper.html

   priv_wrapper aims to help running processes which are dropping
   privileges or are restricting resources in test environments. A
   disabled call always succeeds (i.e. returns 0) and does nothing. The
   system call pledge exists only on OpenBSD.

It is similar in spirit as the rest of the cwrap projects -- see
https://cwrap.org/ -- and several seems to be packaged in Debian:

https://tracker.debian.org/pkg/nss-wrapper
https://tracker.debian.org/pkg/uid-wrapper
https://tracker.debian.org/pkg/socket-wrapper
https://tracker.debian.org/pkg/pam-wrapper

The license appears to be GPLv3+.

/Simon


signature.asc
Description: PGP signature

Bug#986997: ITA: netkit-telnet

[Simon Josefsson]

fre 2021-09-03 klockan 08:47 +0200 skrev Christoph Biedl:
> Simon Josefsson wrote...
> 
> > I'm considering to adopt this package, as it has been orphaned for
> > around five years in Debian.  I wanted to reach out to some people
> > (cc'd) that appear to have been involved in the discussions around
> > it to
> > make sure I'm not missing anything that should be considered.
> 
> My contribution is completely a thing to the past, and should be
> recorded in the related bug reports: This is an entire suite of
> packages
> which - besides being faily old - all suffered from a missing build
> system so I ported it to cmake for the buster release. That was a
> huge
> amount of work and I'm not really proud of the result. Activities
> included contacting upstream, and he eventually provided a copy of
> the
> configuration tool but I stronly doubt it's worth to revive it.
> 
> Long story short, good ride with this package. In case you want some
> more old stories or additional insight, just ping me. Odds are my
> reaction will be "Oh, you're right, I missed that bit".

Thanks for providing some background -- I was a bit surprised to see a
debian-specific cmake build system!  I think it doesn't make a lot of
sense to do any major changes (at least I'm not planning to) until
there is a reasonable upstream, so I have no plans to touch this part
of the package -- but if any future upstream release builds fine, I
would be inclined to drop as many of our patches as possible.

/Simon



signature.asc
Description: This is a digitally signed message part

Bug#986997: ITA: netkit-telnet

[Simon Josefsson]

All,

I'm considering to adopt this package, as it has been orphaned for
around five years in Debian.  I wanted to reach out to some people
(cc'd) that appear to have been involved in the discussions around it to
make sure I'm not missing anything that should be considered.

My aim is to 1) refresh the packaging including hopefully some
autopkgtests, 2) figure out if there is a better upstream for this
package, and 3) prepare to smooth out any issues preventing migrating
towards inetutils in Debian.

I have create a Salsa project and imported unstable debian/ and fixed
some minor issues:

https://salsa.debian.org/jas/netkit-telnet
https://salsa.debian.org/jas/netkit-telnet/-/pipelines

What do you think?

/Simon


signature.asc
Description: PGP signature

Bug#986997: O: netkit-telnet -- basic telnet client

[Simon Josefsson]

Chris Hofstaedtler  writes:

> * Simon Josefsson  [210415 19:06]:
>> Hi!  Upstream is not maintained either -- at least the download URL in
>> netkit-telnet's debian/copyright file does not work.  How about dropping
>> netkit-telnet from Debian?
>
> In #982253 I've expressed that I for one would find that to be a
> good idea. But quite clearly it is work that needs to be a) done and
> b) well coordinated.

I'm happy to work on replacing netkit-based tools with inetutils once
bullseye is out, although Guillem have to agree since he maintains
inetutils in Debian.  If something needs to be modified in inetutils to
be more compatible with netkit, I will help to arrange that.  Starting
with telnet+telnetd seems like a good idea.  As far as I can tell,
telnet is not installed by default on buster nor bullseye which is good.

Btw, the suggestion to symlink telnet to netcat is not a good one:
telnet is a complex protocol, netcat doesn't support any of it as far as
I know.

/Simon


signature.asc
Description: PGP signature

Bug#986997: O: netkit-telnet -- basic telnet client

[Simon Josefsson]

Mattia Rizzolo  writes:

> Hi!
>
> On Thu, Apr 15, 2021 at 12:50:13PM +0200, Simon Josefsson wrote:
>> Hi!  Upstream is not maintained either -- at least the download URL in
>> netkit-telnet's debian/copyright file does not work.  How about dropping
>> netkit-telnet from Debian?  GNU InetUtils provides telnet+telnetd and
>> appears to be actively maintained both in Debian and upstream, and could
>> provide the packages going forward.
>
> Considering how popular telent is, this is a migration that needs to be
> taken with care.
> I have no stake on netkit-telnet myself, and I honestly do not care as
> long as a working `telent` is available.  But since this is the default
> `telnet` it needs to be properly evaluated.

Indeed -- a source code comparison would be great.  I believe InetUtils
sources share the same origin as NetKit, but diverged at some point.
Maybe it is sufficient to compare command line parameters and its
stdin/stdout behaviour (prompting etc).

> For sure any such takeover can only happen in a few months after
> bullseye is released.

That would give plenty of testing time before bullseye+1.

>> Cc'ing Debian maintainer of inetutils too, do
>> you have any comments Guillem?
>
> Overall, with netkit-telnet orphaned, I think the final opinion rests on
> Guillem.  If he believes this is the way forward, I encourage him to
> simply build a transitional package from src:inetutils.

I'm happy to help upstream to make this smoother.

/Simon


signature.asc
Description: PGP signature

Bug#986997: O: netkit-telnet -- basic telnet client

[Simon Josefsson]

Mattia Rizzolo  writes:

> Package: wnpp
>
> The current maintainer of netkit-telnet, Mats Erik Andersson
> , is apparently not active anymore.
> Therefore, this package has been orphaned
>
> Maintaining a package requires time and skills. Please only adopt this
> package if you will have enough time and attention to work on it.
>
> If you want to be the new maintainer, please see
> https://www.debian.org/devel/wnpp/#howto-o for detailed
> instructions how to adopt a package properly.

Hi!  Upstream is not maintained either -- at least the download URL in
netkit-telnet's debian/copyright file does not work.  How about dropping
netkit-telnet from Debian?  GNU InetUtils provides telnet+telnetd and
appears to be actively maintained both in Debian and upstream, and could
provide the packages going forward.  If there is anything missing in
InetUtils compared to netkit-telnet(d), I'm happy to assist from the GNU
InetUtils upstream side.  Cc'ing Debian maintainer of inetutils too, do
you have any comments Guillem?

/Simon

> Some information about this package:
>
> Package: netkit-telnet
> Binary: telnet, telnetd
> Version: 0.17-42
> Maintainer: Debian QA Group 
> Build-Depends: debhelper (>= 10~), libncurses-dev, cmake
> Architecture: any
> Standards-Version: 3.9.8
> Format: 3.0 (quilt)
> Files:
>  5f3c09666f11b4e4ea5b0b4bd4c8e668 1792 netkit-telnet_0.17-42.dsc
>  d6beabaaf53fe6e382c42ce3faa05a36 133749 netkit-telnet_0.17.orig.tar.gz
>  eb4fbbdc55a3b53f7f2ebdc1f857b0cc 36068 netkit-telnet_0.17-42.debian.tar.xz
> Checksums-Sha256:
>  9bfc63c4817be1b1664940b1a85b938822c476f75a537edc8ff025baba9e29cf 1792
> netkit-telnet_0.17-42.dsc
>  9c80d5c7838361a328fb6b60016d503def9ce53ad3c589f3b08ff71a2bb88e00
> 133749 netkit-telnet_0.17.orig.tar.gz
>  1653561178542c85adfba865ec492dd9c4f35bae624f4692c7d55729da679db4
> 36068 netkit-telnet_0.17-42.debian.tar.xz
> Package-List: 
>  telnet deb net standard arch=any
>  telnetd deb net optional arch=any
> Directory: pool/main/n/netkit-telnet
> Priority: source
> Section: net


signature.asc
Description: PGP signature

Bug#966408: RFH: libidn

[Simon Josefsson]

Package: wnpp
Severity: normal

I request assistance with maintaining the libidn package.

Libidn is an old library for internationalized domain names processing,
being phased out in favor of libidn2 that supports the new standards.  I
am upstream author of both libraries, and have also been packaging them
for Debian.

I cannot seem to make maintaining the Debian packages of libidn a
priority, and this has been the case for several years, so I'd like to
ask for help.

I have started to move the packaging to Salsa and package the newly
released upstream version 1.36, but have failed to complete it due to
shared library symbol versioning changes and just the amount of lintian
issues coming up.  I believe it is a good starting point for anyone
taking over, but starting from scratch is fine too.

https://salsa.debian.org/debian/libidn

Feel free to push any changes to a branch in the repo and upload to
experimental and discuss the process forward in this bug report.  I
suggest responding with a ping to this bug report to indicate you are
starting work, in the remote chance that more than one person is looking
at this report at the same time, to enable coordination.

I'm here to help review changes and comment and can still occasionally
make uploads and improve packaging, but more manpower is needed to
primarily get 1.36 uploaded into Debian and be more responsive to
security bugs and other duties.

Thanks,
Simon


signature.asc
Description: PGP signature

Bug#804846: ITP: restund -- modular and flexible STUN and TURN Server

[Simon Josefsson]

Package: wnpp
Severity: wishlist

* Package name: restund
  Version : 0.4.12
  Upstream Author : Alfred E. Heggestad, Richard Aas, Creytiv.com
* URL : http://www.creytiv.com/restund.html
* License : BSD
  Programming Lang: C
  Description : modular and flexible STUN and TURN Server

 Restund is a modular and flexible STUN and TURN Server,
 with IPv4 and IPv6 support.
 .
 The server is designed around the principle of a lightweight core
 using server modules to extend its functionality.
 .
 Some of the modules supported:
 .
  Authentication module
  Binding module
  MySQL module
  Statistics module
  Status module
  Syslog module
  TURN module

/Simon


signature.asc
Description: PGP signature

Bug#636272: Tentative date for upload of libre

[Simon Josefsson]

Vasudev Kamath  writes:

> Vasudev Kamath  writes:
>
>>> If you are looking at baresip and librem, would you be interested in
>>> being in the Uploaders: field for libre as well?  I could surely use
>>> help here, and since they share upstream and discussion mailing list,
>>> you will probably know everything I know about the package too.
>>
>> Sure. I can add you as uploaders to librem and baresip but only problem
>> is I use CDBS for packaging.
>
> Let me provide clarification for word *problem*. I'm not saying I've
> problem with CDBS. I use it because I like it. What I wanted to tell
> Simon is "hey if using CDBS is not a problem for you, are you okay to be
> in uploaders field for librem and baresip too?"

I've added you now.  I'm unfortunately using cdbs for some packages too,
so I know a bit about it.  However, for new packages like this, why
don't you start from scratch and use dh?  I'm happy to do the conversion
if you want.  I think this will save time and reduce frustration going
forward.

/Simon


signature.asc
Description: PGP signature

Bug#636272: Tentative date for upload of libre

[Simon Josefsson]

Den Sun, 01 Nov 2015 08:54:18 +0530
skrev Re: Tentative date for upload of libre:

> Simon Josefsson <si...@josefsson.org> writes:
> 
> > Libre has been in the new queue for 4 days. Thanks for taking care
> > of those packages, they were next on my todo-list.
> 
> Great! thanks. And sorry for not looking at new queue.

The libre package has now been accepted, and I've just made it
team-maintained by pkg-voip in a new upload.

If you are looking at baresip and librem, would you be interested in
being in the Uploaders: field for libre as well?  I could surely use
help here, and since they share upstream and discussion mailing list,
you will probably know everything I know about the package too.

/Simon


pgpmcbVwufOEb.pgp
Description: OpenPGP digital signatur

Bug#636272: Tentative date for upload of libre

[Simon Josefsson]

Libre has been in the new queue for 4 days. Thanks for taking care of those 
packages, they were next on my todo-list.

/Simon

Vasudev Kamath  skrev: (31 oktober 2015 18:01:04 CET)
>
>Control: block 673881 by 636272
>Control: block 673882 by 636272
>
>Hi Simon,
>
>Do you have any tentative date on which you would upload the
>libre?. Because I'm packaging baresip and librem which both need libre
>and I'm currently waiting for libre to enter Debian.
>
>I'll mark my ITP as blocked by yours.
>
>Cheers,

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#636272: restund in debian

[Simon Josefsson]

tis 2015-10-27 klockan 11:15 + skrev Gianfranco Costamagna:
> Hi, please open an RFS bug if you want to find a sponsor.
> 
> Anyway, I looked at the package.
> 
> the packaging rules file is really hacky, but looks good!
> 
> I would appreciate a more sane upstream packaging system, but your workaround
> looks really nice ;)

Thanks for looking at it.  Yeah, upstream's custom make script aren't
the simplest for packaging, but at least they aren't complex to
understand.  I'm a DD so I will upload it when I feel comfortable with
the packaging.

/Simon

> 
> do you mind opening an RFS bug?
> 
> cheers,
> 
> G.
> 
> 
> 
> 
> 
> Il Martedì 27 Ottobre 2015 0:54, Simon Josefsson <si...@josefsson.org> ha 
> scritto:
> I have prepared a Debian package for the latest 0.4.14 release of
> "libre", and have uploaded it to Debian Mentors:
> 
>   http://mentors.debian.net/package/libre
> 
> For reference, upstream homepage and ITP bug links:
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636272
>   http://www.creytiv.com/re.html
> 
> Please review the package, I want it to be in perfect condition!
> Anything that appears sub-optimal is something I want to learn about.
> 
> As you can see, the build system is ad-hoc, which is always a challenge
> for shared libraries.  I'm not certain the way the soname, symbol list,
> and everything around the shared library part is kosher.
> 
> A temporary git repository for the packaging exists.  I plan to move
> this to alioth before proper upload to Debian, hoping to make this a
> pkg-voip team maintained package.
> 
>   https://github.com/jas4711/libre-dpkg
> 
> /Simon



signature.asc
Description: This is a digitally signed message part

Bug#636272: restund in debian

[Simon Josefsson]

I have prepared a Debian package for the latest 0.4.14 release of
"libre", and have uploaded it to Debian Mentors:

  http://mentors.debian.net/package/libre

For reference, upstream homepage and ITP bug links:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636272
  http://www.creytiv.com/re.html

Please review the package, I want it to be in perfect condition!
Anything that appears sub-optimal is something I want to learn about.

As you can see, the build system is ad-hoc, which is always a challenge
for shared libraries.  I'm not certain the way the soname, symbol list,
and everything around the shared library part is kosher.

A temporary git repository for the packaging exists.  I plan to move
this to alioth before proper upload to Debian, hoping to make this a
pkg-voip team maintained package.

  https://github.com/jas4711/libre-dpkg

/Simon


signature.asc
Description: PGP signature

Bug#694025: Debian package of 'Oz' uploaded to mentors.debian.net

[Simon Josefsson]

Hi Chris.  Good to hear from you.  No, I don't need anything in
particular now.  The reason for mailing was to confirm that I'm not
stepping in a direction that everyone has abandoned for good reasons
years ago (the old ITP for Oz in Debian just expired without any
comment). That doesn't seem to be the case, so I'll upload Oz into
Debian shortly.

There is a Oz pull request to add Debian 8 jessie support that would
be nice to have merged, but it is not urgent:
https://github.com/clalancette/oz/pull/184

/Simon

 Hi Simon,
  I'm sorry I haven't been communicative in the last few days.  I
 know you have sent me several emails.  Thanks for working on getting
 Oz into Debian.  There have been several false starts in the past, so
 it is good to see it making progress.  Is there anything you need from
 me right now?  I don't have a ton of time in the immediate future, but
 if there is something you need urgently I may be able to do it this
 weekend.  Just let me know.
 
 Thanks,
 Chris Lalancette
 
 
 
 On Fri, Apr 17, 2015 at 7:32 AM, Simon Josefsson
 si...@josefsson.org wrote:
  On Fri, Apr 17, 2015 at 01:19:53PM +0200, Simon Josefsson wrote:
   Do you see any problem including Oz in Debian?  The tools look
   complementary, and Oz provide some value to me.  I've added a
   pointer to the virt-install and virt-builder tools to the Oz
   package description now.
 
  No problem at all - in Fedora we ship both tools.
 
  Excellent.
 
  If you or someone else wants to co-maintain the Debian package, that
  would be great as I could use the help.  I'm happy
  group-maintaining it too, but I'm not sure which of the various
  cloud-related Debian groups are active or relevant.
 
  Seems we lost Chris on cc, adding him back.  Do you want to help
  maintain it in Debian?
 
  /Simon



pgpkxwohZMSbJ.pgp
Description: OpenPGP digital signatur

Bug#694025: Debian package of 'Oz' uploaded to mentors.debian.net

[Simon Josefsson]

Den Thu, 16 Apr 2015 19:01:58 +0100
skrev Bug#694025: Debian package of 'Oz' uploaded to mentors.debian.net:

 On Thu, Apr 16, 2015 at 07:24:26PM +0200, Simon Josefsson wrote:
  Thanks for the pointer.  Trying it out, it looks to me that they
  don't offer the same functionality.  virt-builder downloads an
  image that someone else prepared (not sure how?)
 
 At the moment using:
 https://github.com/libguestfs/libguestfs/blob/master/builder/website/debian.sh
 but I intend to get out of the business of building disk images for
 virt-builder, and use the cloud images prepared by distros.

Nice pointer.  That script does some of what I use oz for, but oz helps
me with libvirt XML creation.  And it has a manpage :-)

  To reduce confusion, maybe a small discussion in the package
  description or README.Debian is appropriate to explain the
  differences.
  
  Btw, thanks for doing the Oz Debian packaging.  Was there any reason
  it wasn't uploaded back then?
 
 That's a good question -- I don't actually recall at all :-/

Do you see any problem including Oz in Debian?  The tools look
complementary, and Oz provide some value to me.  I've added a pointer
to the virt-install and virt-builder tools to the Oz package
description now.

I'll wait a few days for further comments, and then I plan to upload
into NEW.  Hopefully my Oz patch to support Debian 8 Jessie will be
merged by then too.

/Simon


pgpcNqAs2xUuC.pgp
Description: OpenPGP digital signatur

Bug#694025: Debian package of 'Oz' uploaded to mentors.debian.net

[Simon Josefsson]

 On Fri, Apr 17, 2015 at 01:19:53PM +0200, Simon Josefsson wrote:
  Do you see any problem including Oz in Debian?  The tools look
  complementary, and Oz provide some value to me.  I've added a
  pointer to the virt-install and virt-builder tools to the Oz package
  description now.
 
 No problem at all - in Fedora we ship both tools.

Excellent.

If you or someone else wants to co-maintain the Debian package, that
would be great as I could use the help.  I'm happy group-maintaining it
too, but I'm not sure which of the various cloud-related Debian groups
are active or relevant.

Seems we lost Chris on cc, adding him back.  Do you want to help
maintain it in Debian?

/Simon


pgpqtsLJ3GsRe.pgp
Description: OpenPGP digital signatur

Bug#694025: Debian package of 'Oz' uploaded to mentors.debian.net

[Simon Josefsson]

Hi.

I recently found myself setting up a libvirtd/KVM-based virtual
machine, and needed a way to build VM images from the command line.  I
searched around, and found the Oz project:

https://github.com/clalancette/oz/wiki

Testing Oz on a newly installed Jessie rc2 machine I found that it
seemed to work.  At least I was able to create VM images for Debian
Wheezy and Jessie easily.  Thus I decided to respin the old ITP for Oz:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=694025

I have uploaded a package to mentors for easy review:

https://mentors.debian.net/package/oz

If you want to check out the Debian packaging you can get:

https://github.com/jas4711/oz-dpkg

With this, I'm asking for review/support/objections before uploading
this into Debian properly.

/Simon


pgp3chByN_wZ8.pgp
Description: OpenPGP digital signatur

Bug#694025: Debian package of 'Oz' uploaded to mentors.debian.net

[Simon Josefsson]

Den Thu, 16 Apr 2015 15:55:43 +0100
skrev Bug#694025: Debian package of 'Oz' uploaded to mentors.debian.net:

 On Thu, Apr 16, 2015 at 04:35:14PM +0200, Simon Josefsson wrote:
  Hi.
  
  I recently found myself setting up a libvirtd/KVM-based virtual
  machine, and needed a way to build VM images from the command
  line.  I searched around, and found the Oz project:
  
  https://github.com/clalancette/oz/wiki
  
  Testing Oz on a newly installed Jessie rc2 machine I found that it
  seemed to work.  At least I was able to create VM images for Debian
  Wheezy and Jessie easily.  Thus I decided to respin the old ITP for
  Oz:
  
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=694025
  
  I have uploaded a package to mentors for easy review:
  
  https://mentors.debian.net/package/oz
  
  If you want to check out the Debian packaging you can get:
  
  https://github.com/jas4711/oz-dpkg
  
  With this, I'm asking for review/support/objections before uploading
  this into Debian properly.
 
 On sufficiently new Debian you can also do:
 
   $ virt-builder debian-7
 
 (and no need for root privileges).

Thanks for the pointer.  Trying it out, it looks to me that they don't
offer the same functionality.  virt-builder downloads an image that
someone else prepared (not sure how?) and adapts it.  oz-install
creates a new image by booting a normal d-i ISO together with
preseeding. Is it possible to do that with virt-builder? For my
purposes, oz-install's approach is even better than virt-install's
approach of doing debootstrapping, since I want the full D-I
experience.  So these tools look complementary to me.

To reduce confusion, maybe a small discussion in the package
description or README.Debian is appropriate to explain the differences.

Btw, thanks for doing the Oz Debian packaging.  Was there any reason
it wasn't uploaded back then?

Thanks,
/Simon


pgpus8hV8Y8Xn.pgp
Description: OpenPGP digital signatur

Bug#779837: ITP: yubico-piv-tool -- YubiKey NEO PIV tool

[Simon Josefsson]

The package has been uploaded to mentors:

http://mentors.debian.net/package/yubico-piv-tool

Review of the package would be appreciated!

/Simon


pgpn3fZ8b715U.pgp
Description: OpenPGP digital signatur

Bug#779837: ITP: yubico-piv-tool -- YubiKey NEO PIV tool

[Simon Josefsson]

Package: wnpp
Severity: wishlist

* Package name: yubico-piv-tool
  Version : 0.1.5
  Upstream Author : Klas Lindfors
* URL : https://developers.yubico.com/yubico-piv-tool/
* License : GPL-3.0+ with OpenSSL exception
  Programming Lang: C
  Description : YubiKey NEO PIV tool

 The Yubico PIV tool is used for interacting with the Privilege and
 Identification Card (PIV) applet on a YubiKey NEO.
 With it you may generate keys on the device, importing keys and
 certificates, and create certificate requests, and other operations.
 A shared library and a command-line tool is included.

Debian packaging being worked on in Git:
https://github.com/Yubico/yubico-piv-tool-dpkg

/Simon


pgpcEUQsWnSvf.pgp
Description: OpenPGP digital signatur

Bug#776091: ITP: pam-u2f -- Universal 2nd Factor PAM Module

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: si...@josefsson.org

* Package name: pam-u2f
  Version : 0.0.1
  Upstream Author : Alessio Di Mauro
* URL : https://developers.yubico.com/pam-u2f/
* License : BSD
  Programming Lang: C
  Description : Universal 2nd Factor (U2F) PAM Module

 The PAM U2F module provides an easy way to integrate the Yubikey (or
 other U2F-compliant authenticators) into your existing user
 authentication infrastructure. PAM is used by GNU/Linux, Solaris and
 Mac OS X for user authentication.

Debian packaging:
https://github.com/Yubico/pam-u2f-dpkg

/Simon


pgpNHPU9VnUC8.pgp
Description: OpenPGP digital signatur

Bug#775597: ITP: libu2f-server -- Universal 2nd Factor Server C Library

[Simon Josefsson]

Package: wnpp
Severity: wishlist

* Package name: libu2f-server
  Version : 0.0.0
  Upstream Author : Alessio Di Mauro, Simon Josefsson
* URL : https://developers.yubico.com/libu2f-server/
* License : BSD
  Programming Lang: C
  Description : Universal 2nd Factor (U2F) Server C Library

 This is a C library that implements the server-side of the U2F
 protocol. More precisely, it provides an API for generating the JSON
 blobs required by U2F devices to perform the U2F Registration and U2F
 Authentication operations, and functionality for verifying the
 cryptographic operations. The package contains a C library, a command
 line tool, and documentation.

Debian packaging:
https://github.com/Yubico/libu2f-server-dpkg

/Simon


pgpIL6_vhXdn3.pgp
Description: OpenPGP digital signatur

Bug#765177: ITP: yubikey-neo-manager -- YubiKey NEO management graphical user interface

[Simon Josefsson]

Package: wnpp
Severity: wishlist

* Package name: yubikey-neo-manager
  Version : 0.2.2
  Upstream Author : Dain Nilsson
* URL : https://developers.yubico.com/yubikey-neo-manager/
* License : BSD-2-clause
  Programming Lang: Python
  Description : YubiKey NEO management graphical user interface

 The YubiKey NEO support One-Time Password (OTP), smartcard CCID/PCSC,
 and Universal 2nd Factor (U2F) protocols, and this application allows
 you to interface to various parts of the device, including
 mode-switching.

Debian packaging being worked on in Git:
https://github.com/Yubico/yubikey-neo-manager-dpkg

Uploaded to mentors for review:
https://mentors.debian.net/package/yubikey-neo-manager

/Simon


signature.asc
Description: PGP signature

Bug#764262: ITP: libu2f-host: Universal 2nd Factor host communication C Library

[Simon Josefsson]

Package: wnpp
Severity: wishlist

* Package name: libu2f-host
  Version : 0.0
  Upstream Author : Klas Lindfors, Simon Josefsson
* URL : https://developers.yubico.com/libu2f-host/
* License : GPL-3+
  Programming Lang: C
  Description : Universal 2nd Factor (U2F) host communication C Library

 Libu2f is a package for doing Universal 2nd Factor (U2F) host
 communication and has functionality for the Registration and
 Authentication operations. The package contains a C library, a command
 line tool, and documentation.

Debian packaging (lintian free) in Git:
https://github.com/Yubico/libu2f-host-dpkg

Uploaded to mentors for review:
https://mentors.debian.net/package/libu2f-host

/Simon


signature.asc
Description: PGP signature

Bug#745139: ITP: libykneomgr -- Yubico YubiKey NEO Manager library and tool

[Simon Josefsson]

Package: wnpp
Severity: wishlist

 * Package name: libykneomgr
   Version : 0.1.2-1
   Upstream Author : Simon Josefsson si...@yubico.com
 * URL : http://opensource.yubico.com/libykneomgr/
 * License : LGPLv3+
   Section : utils

 This is a C library to interact with the YubiKey NEO.  There is a
 command line tool ykneomgr for interactive use.  It supports
 querying the YubiKey NEO for firmware version, operation mode
 (OTP/CCID) and serial number.  You may also mode switch the device and
 manage applets (list, delete and install).

The Debian package is available on mentors for review:
https://mentors.debian.net/package/libykneomgr

Source code for the Debian package is available here:
https://github.com/Yubico/libykneomgr-dpkg

/Simon


-- 
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/20140418130442.6316e...@latte.josefsson.org

Bug#656142: ITP: duff -- Duplicate file finder

[Simon Josefsson]

Kamal Mostafa ka...@whence.com writes:

 Package: wnpp
 Severity: wishlist
 Owner: Kamal Mostafa ka...@whence.com


 * Package name: duff
   Version : 0.5
   Upstream Author : Camilla Berglund elmindr...@elmindreda.org
 * URL : http://duff.sourceforge.net/
 * License : Zlib
   Programming Lang: C
   Description : Duplicate file finder

 Duff is a command-line utility for identifying duplicates in a given set of
 files.  It attempts to be usably fast and uses the SHA family of message
 digests as a part of the comparisons.

If there aren't warnings about use of SHA1 in the tool, there should be.
While I don't recall any published SHA1 collisions, SHA1 is considered
broken and shouldn't be used if you want to trust your comparisons.  I'm
assuming the tool supports SHA256 and other SHA2 hashes as well?  It
might be useful to make sure the defaults are non-SHA1.

/Simon



-- 
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/87wr8qk8r5@latte.josefsson.org

Bug#655927: ITP: smartcardpp -- C++ library for accessing Smart Cards

[Simon Josefsson]

Martin-Éric Racine martin-eric.rac...@iki.fi writes:

 Package: wnpp
 Severity: wishlist
 Owner: Martin-Éric Racine martin-eric.rac...@iki.fi

 * Package name: smartcardpp
   Version : 0.3.0
   Upstream Author : Kalev Lember ka...@smartlink.ee  others
 * URL : http://code.google.com/p/esteid/
 * License : LGPL 2.1
   Programming Lang: C++
   Description : C++ library for accessing Smart Cards

 smartcardpp is a set of C++ classes to manage Smart Card
 communications and to implement basic command primitives.
 .
 This package provides the runtime libraries.

 *

 This package is one of 6 packages created by the Estonian government 
 to support national ID cards on Free Software operating systems.

 This particular package is one of the core libraries used to access
 and manipulate the data on the ID cards.

 The whole suite is comprised of the following source packages:

 smartcardpp
 libdigidoc
 libdigidocpp
 qesteidutil
 qdigidoc
 esteid-browser-plugin

Is this package applicable to any smartcard, or just to Estonian EID?
The package name sounds quite generic, but from the description it seems
less clear.

/Simon



--
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/8739bgoj9p@latte.josefsson.org

Bug#655348: ITP: quicktun -- QuickTun is a simple VPN tunnel relying on NaCl library

[Simon Josefsson]

Sergiusz Pawlowicz deb...@pawlowicz.name writes:

 Package: wnpp
 Severity: wishlist
 Owner: Sergiusz Pawlowicz deb...@pawlowicz.name

 * Package name: quicktun
   Version : 2.1.7
   Upstream Author : Ivo Smits i...@ucis.nl
 * URL : http://wiki.ucis.nl/QuickTun
 * License : Public domain (preserve copyright notice)

What license is that?  Looking at the source code files, they have
headers like the one below.  It seems BSD-like to me.

/Simon

/* Copyright 2010 Ivo Smits i...@ucis.nl. All rights reserved.
Redistribution and use in source and binary forms, with or without 
modification, are
permitted provided that the following conditions are met:

1. Redistributions of source code must retain the above copyright notice, this 
list of
conditions and the following disclaimer.

2. 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.

THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF 
MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS 
OR
CONTRIBUTORS 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.

The views and conclusions contained in the software and documentation are those 
of the
authors and should not be interpreted as representing official policies, either 
expressed
or implied, of Ivo Smits.*/



-- 
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/8762gjcngj@latte.josefsson.org

Bug#655348: ITP: quicktun -- QuickTun is a simple VPN tunnel relying on NaCl library

[Simon Josefsson]

ons 2012-01-11 klockan 00:08 + skrev Sergiusz Pawlowicz:
 On Tue, Jan 10, 2012 at 20:27, Simon Josefsson si...@josefsson.org wrote:
  Sergiusz Pawlowicz deb...@pawlowicz.name writes:
 
  Package: wnpp
  Severity: wishlist
  Owner: Sergiusz Pawlowicz deb...@pawlowicz.name
 
  * Package name: quicktun
Version : 2.1.7
Upstream Author : Ivo Smits i...@ucis.nl
  * URL : http://wiki.ucis.nl/QuickTun
  * License : Public domain (preserve copyright notice)
 
  What license is that?  Looking at the source code files, they have
  headers like the one below.  It seems BSD-like to me.
 
  /Simon
 
  /* Copyright 2010 Ivo Smits i...@ucis.nl. All rights reserved.
  Redistribution and use in source and binary forms, with or without 
  modification, are
  permitted provided that the following conditions are met:
 
  1. Redistributions of source code must retain the above copyright notice, 
  this list of
  conditions and the following disclaimer.
 
  2. 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.
 
  THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
  WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF 
  MERCHANTABILITY AND
  FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE 
  AUTHORS OR
  CONTRIBUTORS 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.
 
  The views and conclusions contained in the software and documentation are 
  those of the
  authors and should not be interpreted as representing official policies, 
  either expressed
  or implied, of Ivo Smits.*/
 
 Hi, so how should I choose the license, from licenses suggested by
 Debian? Please be more constructive, I cannot see anything like
 BSD-like, but I am not a lawyer, though.

Looking at this page:

http://dep.debian.net/deps/dep5/

The link for BSD-2-clause is to:

http://spdx.org/licenses/BSD-2-Clause

That text looks quite similar to the license text above, so I would
recommend 'License: BSD-2-clause'.

/Simon





-- 
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/1326264511.2485.13.ca...@latte.josefsson.org

Bug#633837: libidn11: German ß (LATIN SMALL LETTER SHARP S) should no longer be converted to ss

[Simon Josefsson]

Christian Hammers chamm...@netcologne.de writes:

 On Thu, 14 Jul 2011 10:24:46 +0200
 Simon Josefsson si...@josefsson.org wrote:

 Christian Hammers chamm...@netcologne.de writes:
 
  Package: libidn11
  Version: 1.15-2
  Severity: normal
 
 
  Quoting
  http://www.denic.de/en/domains/internationalized-domain-names/sharp-s.html
  Since 4 August 2010, the IDNAbis standard allows the Latin small
  letter sharp s –
  also known as Eszett or sharp s (ß) – to be used as part of
  a domain name
 
  The IDN library (1.15 as well as 1.22 from unstable) still
  converts it to ss:
 
  $ idn --quiet --idna-to-ascii baß.de
  bass.de
 
  Changing the behaviour will of course break backwards compatibility but
  as the compatibility was broken by the IDNA standard itself, the library
  should continue to follow the standard (at least in methods that have
  idna in their name).
 
 Hi Christian.  libidn.so implements the old IDNA standard, retroactively
 called IDNA2003.
 
 The page above talks about IDNAbis, or usually called IDNA2008, which
 libidn.so and idn don't support.  IDNA2008 and IDNA2003 are not
 compatible.
 
 The GNU Libidn project contains another library and tool, libidn2 and
 idn2, which implements the IDNA2008 algorithm.  It works like this:
 
 jas@latte:~$ idn2  baß.de
 xn--ba-hia.de
 jas@latte:~$ 
 
 So I believe your request should be re-categorised as 1) a request to
 package libidn2, and 2) modify any applications you are concerned with
 to support it.  If you just want to do the conversions on the command
 line, 1) will suffice.
 
 I'll see if I can get some packaging up and running...

 I would rather have libidn2 treated just as an update to libidn11 i.e.
 package idn (2.0), libidn-dev (2.0) and libidn20 (2.0) that
 replace the current /usr/bin/idn tool in the next Debian release.
 (or libidn2 if the linker figures correctly that it is newer than 
 libidn11)

That won't work -- IDNA2003 and IDNA2008 are fundamentally (at the
specification level) so different that you can't replace one with the
other.  The APIs of the libraries are also different.

Further, IDNA2003 will continue to be useful in parallel to IDNA2008,
and vice versa.

/Simon



--
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/87hb6pfbnk@latte.josefsson.org

Bug#633837: libidn11: German ß (LATIN SMALL LETTER SHARP S) should no longer be converted to ss

[Simon Josefsson]

Christian Hammers chamm...@netcologne.de writes:

 package: wnpp
 retitle 633837 RFP: libidn2 (for IDNA2008 support including the SHARP S 
 letter)
 severity 633837 wishlist
 stop

 (see below)

 On Thu, 14 Jul 2011 11:34:55 +0200
 Simon Josefsson si...@josefsson.org wrote:

 Christian Hammers chamm...@netcologne.de writes:
 
  On Thu, 14 Jul 2011 10:24:46 +0200
  Simon Josefsson si...@josefsson.org wrote:
 
  Christian Hammers chamm...@netcologne.de writes:
  
   Package: libidn11
   Version: 1.15-2
   Severity: normal
  
  
   Quoting
   http://www.denic.de/en/domains/internationalized-domain-names/sharp-s.html
   Since 4 August 2010, the IDNAbis standard allows the Latin small
   letter sharp s –
   also known as Eszett or sharp s (ß) – to be used as part of
   a domain name
  
   The IDN library (1.15 as well as 1.22 from unstable) still
   converts it to ss:
  
   $ idn --quiet --idna-to-ascii baß.de
   bass.de
  
   Changing the behaviour will of course break backwards compatibility but
   as the compatibility was broken by the IDNA standard itself, the library
   should continue to follow the standard (at least in methods that have
   idna in their name).
  
  Hi Christian.  libidn.so implements the old IDNA standard, retroactively
  called IDNA2003.
  
  The page above talks about IDNAbis, or usually called IDNA2008, which
  libidn.so and idn don't support.  IDNA2008 and IDNA2003 are not
  compatible.
  
  The GNU Libidn project contains another library and tool, libidn2 and
  idn2, which implements the IDNA2008 algorithm.  It works like this:
  
  jas@latte:~$ idn2  baß.de
  xn--ba-hia.de
  jas@latte:~$ 
  
  So I believe your request should be re-categorised as 1) a request to
  package libidn2, and 2) modify any applications you are concerned with
  to support it.  If you just want to do the conversions on the command
  line, 1) will suffice.
  
  I'll see if I can get some packaging up and running...
 
  I would rather have libidn2 treated just as an update to libidn11 i.e.
  package idn (2.0), libidn-dev (2.0) and libidn20 (2.0) that
  replace the current /usr/bin/idn tool in the next Debian release.
  (or libidn2 if the linker figures correctly that it is newer than 
  libidn11)
 
 That won't work -- IDNA2003 and IDNA2008 are fundamentally (at the
 specification level) so different that you can't replace one with the
 other.  The APIs of the libraries are also different.
 
 Further, IDNA2003 will continue to be useful in parallel to IDNA2008,
 and vice versa.

 Then I re-categorise it as Request-For-Packaging. Anibal, will you package
 idn2 as well?

I'm working on libidn2 packaging, I'll make them public later today and
will upload to mentors.debian.net so you can test it.  I'd be very happy
if Anibal could help with them.

/Simon



--
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/87hb6pcc0z@latte.josefsson.org

Bug#633837: libidn11: German ß (LATIN SMALL LETTER SHARP S) should no longer be converted to ss

[Simon Josefsson]

retitle 633837 RFS: libidn2 for IDNA2008 support including the SHARP S letter
thanks

Simon Josefsson si...@josefsson.org writes:

 Christian Hammers chamm...@netcologne.de writes:

 package: wnpp
 retitle 633837 RFP: libidn2 (for IDNA2008 support including the
 SHARP S letter)
 severity 633837 wishlist
 stop

 (see below)

 On Thu, 14 Jul 2011 11:34:55 +0200
 Simon Josefsson si...@josefsson.org wrote:

 Christian Hammers chamm...@netcologne.de writes:
 
  On Thu, 14 Jul 2011 10:24:46 +0200
  Simon Josefsson si...@josefsson.org wrote:
 
  Christian Hammers chamm...@netcologne.de writes:
  
   Package: libidn11
   Version: 1.15-2
   Severity: normal
  
  
   Quoting
   http://www.denic.de/en/domains/internationalized-domain-names/sharp-s.html
   Since 4 August 2010, the IDNAbis standard allows the Latin small
   letter sharp s –
   also known as Eszett or sharp s (ß) – to be used as part of
   a domain name
  
   The IDN library (1.15 as well as 1.22 from unstable) still
   converts it to ss:
  
   $ idn --quiet --idna-to-ascii baß.de
   bass.de
  
   Changing the behaviour will of course break backwards compatibility but
   as the compatibility was broken by the IDNA standard itself, the 
   library
   should continue to follow the standard (at least in methods that have
   idna in their name).
  
  Hi Christian.  libidn.so implements the old IDNA standard, retroactively
  called IDNA2003.
  
  The page above talks about IDNAbis, or usually called IDNA2008, which
  libidn.so and idn don't support.  IDNA2008 and IDNA2003 are not
  compatible.
  
  The GNU Libidn project contains another library and tool, libidn2 and
  idn2, which implements the IDNA2008 algorithm.  It works like this:
  
  jas@latte:~$ idn2  baß.de
  xn--ba-hia.de
  jas@latte:~$ 
  
  So I believe your request should be re-categorised as 1) a request to
  package libidn2, and 2) modify any applications you are concerned with
  to support it.  If you just want to do the conversions on the command
  line, 1) will suffice.
  
  I'll see if I can get some packaging up and running...
 
  I would rather have libidn2 treated just as an update to libidn11 i.e.
  package idn (2.0), libidn-dev (2.0) and libidn20 (2.0) that
  replace the current /usr/bin/idn tool in the next Debian release.
  (or libidn2 if the linker figures correctly that it is newer than 
  libidn11)
 
 That won't work -- IDNA2003 and IDNA2008 are fundamentally (at the
 specification level) so different that you can't replace one with the
 other.  The APIs of the libraries are also different.
 
 Further, IDNA2003 will continue to be useful in parallel to IDNA2008,
 and vice versa.

 Then I re-categorise it as Request-For-Packaging. Anibal, will you package
 idn2 as well?

 I'm working on libidn2 packaging, I'll make them public later today and
 will upload to mentors.debian.net so you can test it.  I'd be very happy
 if Anibal could help with them.

Done now, please see:

http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=libidn2-0

Git repository for the debian/ stuff:

https://gitorious.org/libidn2/libidn2-dpkg

Please review or yet better, send patches. :-)

/Simon



--
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/87wrflavua@latte.josefsson.org

Bug#611133: ITP: iucode-tool -- Intel Processor microcode tool

[Simon Josefsson]

Henrique de Moraes Holschuh h...@debian.org writes:

 * Package name: iucode-tool
...
 It requires non-free microcode data downloaded directly from Intel or
 installed by the intel-microcode package in order to be able to update
 the system processors.

Would that be in main or contrib?  By the description it looks like it
would be in contrib to me, but possibly there is free microcode
available too?

/Simon



-- 
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/87vd1cwsrk@latte.josefsson.org

Bug#608155: Packages are available for testing

[Simon Josefsson]

Packages are available from:

Debian: http://download.savannah.gnu.org/releases/oath-toolkit/dpkg/
Ubuntu: https://launchpad.net/~simon-josefsson/+archive/ppa-simon-josefsson
Git: http://gitorious.org/oath-toolkit/oath-toolkit-dpkg

I am now looking for a DD that is interested in sponsoring this.  I'm a
debian maintainer, so I can do uploads myself after the initial
sponsored upload.

/Simon



-- 
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/8739os4mg4@latte.josefsson.org

Bug#608155: Packages on mentors.debian.net

[Simon Josefsson]

Debian packages are available on mentors.debian.net too:

http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=oath-toolkit

/Simon



-- 
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/87fwss34sw@latte.josefsson.org

Bug#608155: ITP: oath-toolkit -- OATH Toolkit

[Simon Josefsson]

Package: wnpp
Severity: wishlist

* Package name : oath-toolkit
Version : 1.2.0
Upstream Author : Simon Josefsson si...@josefsson.org
* URL : http://www.nongnu.org/hotp-toolkit/oath-toolkit/
* License : LGPLv2+, GPLv3+
Description : 

The OATH Toolkit attempts to collect several tools that are useful
when deploying technologies related to OATH.  For example, see RFC
4226 on OATH HOTP.  The components included in the package is:

   * liboath: A shared and static C library for OATH handling.

   * oathtool: A command line tool for generating and validating OTPs.

   * pam_oath: A PAM module for pluggable login authentication for OATH.

See each sub-directory for more information.

/Simon



-- 
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/87tyhyx20u@latte.josefsson.org

Bug#596511: ITP: simon -- Open source speech recognition

[Simon Josefsson]

Peter Grasch gra...@simon-listens.org writes:

 Peter, have you prepared a source *.deb yet?  It would be interesting to
 look at the code to understand how critical the non-free component is.
 Sure. There are complete packages in the Ubuntu ppa:
 https://launchpad.net/~grasch-simon-listens/+archive/simon/

The copyright file says:

This package consists of four differently licensed parts:
  * The documentation is under the GFDL (see below);
  * Julius (everything in the folder julius/) is coverd
by the Julius license (see below)
  * CMake modules are licensed under the BSD license
(see below)
  * Everything else is covered by the GPLv2

One conclusion from earlier discussions about the Julius license on
debian-legal was that it was non-free:

http://www.mail-archive.com/debian-le...@lists.debian.org/msg40898.html

The thread isn't completely clear to me what the exact problem is
though...

Is Julius dynamically linked to Simon?  I wonder whether GPLv2 is
compatible with the Julius license.

/Simon



-- 
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/87mxrbz11k@mocca.josefsson.org

Bug#596511: ITP: simon -- Open source speech recognition

[Simon Josefsson]

Peter Grasch gra...@simon-listens.org writes:

  Hi!

 One conclusion from earlier discussions about the Julius license on
 debian-legal was that it was non-free:

 http://www.mail-archive.com/debian-le...@lists.debian.org/msg40898.html

 The thread isn't completely clear to me what the exact problem is
 though...
 As far as I can work out the ambiguous advertising clause is the
 problem (as well as possibly clause 5 but that seems to be open for
 discussion).

 I agree that this clause is quite badly worded and already asked about
 it in the Julius forums (I am bedahr):
 http://julius.sourceforge.jp/forum/viewtopic.php?f=6t=644-

 But I never got a reply.


OK.

 Is Julius dynamically linked to Simon?  I wonder whether GPLv2 is
 compatible with the Julius license.
 Yes it is. The simon license contains a special exception to allow this.
 This is also covered here:
 http://www.simon-listens.org/wiki/index.php/Licensing

It refers to 'under certain conditions as described in each individual
source file' but I cannot find conditions described in any of a random
sample I made of source code files in Simon?  Can you point to one file
that has the conditions?  All source code files that are built into a
package linked to Julius needs to have the exception, I believe,
otherwise the file is under the GPLv2+ only without the exception.

Also, any external GPL code that Simon links to needs to have the same
exception.  Is there any external GPL code?

/Simon



-- 
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/87lj6vxisf@mocca.josefsson.org

Bug#596511: ITP: simon -- Open source speech recognition

[Simon Josefsson]

Peter Grasch gra...@simon-listens.org writes:

  Hi!

 Am 2010-09-21 16:39, schrieb Simon Josefsson:
 Is Julius dynamically linked to Simon?  I wonder whether GPLv2 is
 compatible with the Julius license.
 Yes it is. The simon license contains a special exception to allow this.
 This is also covered here:
 http://www.simon-listens.org/wiki/index.php/Licensing
 It refers to 'under certain conditions as described in each individual
 source file' but I cannot find conditions described in any of a random
 sample I made of source code files in Simon?  Can you point to one file
 that has the conditions?  All source code files that are built into a
 package linked to Julius needs to have the exception, I believe,
 otherwise the file is under the GPLv2+ only without the exception.
 You are right, I forgot that exception but added it to the two files
 of the one class coming in direct contact with Julius (it's used
 somewhere else too but there it just calls external programs).


 Also, any external GPL code that Simon links to needs to have the same
 exception.  Is there any external GPL code?
 Well of course - KDE.

I believe kdelibs is LGPL, so maybe you are OK.  It depends on what
parts of KDE is used.

 This is getting ridiculously frustrating. It's not that I don't think
 it's an important issue but I guess if you'd gather all involved
 parties and ask them if the current setup would be ok I am pretty sure
 everyone would agree. Oh well I guess that just comes with the
 territory.

I know the pain, I've ended up rewriting several projects because of
license problems with earlier implementations.  What I have learned is
that you should react to license issues as soon as possible, or you'll
end up investing a lot of work into something that needs to be
redesigned.

 I obviously can't hack this into simon 0.3.0 but for the next version,
 would it help if I split the Julius-interfacing part into a plugin
 that doesn't link to KDE? This would be the easiest option in my
 opinion but  as I understand it it would mean to distribute the plugin
 seperately?

 If Julius is not free in Debian eyes this would mean that simon
 becomes pretty much useless to be honest.

I don't really have an opinion whether it is free or not yet, but it
looks complicated.

/Simon



-- 
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/87tylirfuc@mocca.josefsson.org

Bug#596511: ITP: simon -- Open source speech recognition

[Simon Josefsson]

Peter Grasch gra...@simon-listens.org writes:

 Package: wnpp
 Severity: wishlist
 Owner: Peter Grasch gra...@simon-listens.org


 * Package name: simon
   Version : 0.3.0
   Upstream Author : Peter Grasch gra...@simon-listens.org
 * URL : http://www.simon-listens.org/
 * License : GPL, BSD, GFDL and Julius
   Programming Lang: C, C++
   Description : Open source speech recognition

  With simon you can control your computer with your voice. You can 
  open programs, URLs, type configurable text snippets, simulate 
  shortcuts, control the mouse and keyboard and much more.
  simon is not bound to any language and works with any dialect.
  This project utilizes the open source large vocabulary continuous 
  speech recognition engine Julius (this package ships its own 
  modified version).

Is this intended for main?  Doesn't Julius rely on the non-free HTK
toolkit?

/Simon



-- 
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/87y6b4ckiq@mocca.josefsson.org

Bug#585567: ITP: gobi-loader -- Firmware loader for Qualcomm Gobi USB chipsets.

[Simon Josefsson]

Mark Hymers m...@debian.org writes:

 On Fri, 11, Jun, 2010 at 10:34:10PM +0200, Simon Josefsson spoke thus..
 This package would be useful, I have a Lenovo X201 with this chipset.
 
 However, is the program useful without non-free firmware?  If not,
 perhaps it belongs in contrib rather than main?

 I've just uploaded it to contrib.  I'm not sure where in the ITP you
 read that I was going to upload it to main...

Oh great.  I searched for 'contrib' and 'non-free', and not finding it,
I assumed it was going to main.  I'll try to test it...

Thanks,
/Simon



-- 
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/87k4q469fg@mocca.josefsson.org

Bug#585567: ITP: gobi-loader -- Firmware loader for Qualcomm Gobi USB chipsets.

[Simon Josefsson]

Mark Hymers m...@debian.org writes:

 Package: wnpp
 Severity: wishlist
 Owner: Mark Hymers m...@debian.org

 * Package name: gobi-loader
   Version : 0.6
   Upstream Author : Matthew Garrett / RedHat m...@redhat.com
 * URL : http://www.codon.org.uk/~mjg59/gobi_loader/
 * License : GPL 2
   Programming Lang: C
   Description : Firmware loader for Qualcomm Gobi USB chipsets.

  gobi-loader is a firmware loader for Qualcomm Gobi USB
  chipsets. These devices appear in an uninitialised state when power
  is applied and require firmware to be loaded before they can be used
  as modems. gobi-loader adds a udev rule that will trigger loading of
  the firmware and make the modem usable.

This package would be useful, I have a Lenovo X201 with this chipset.

However, is the program useful without non-free firmware?  If not,
perhaps it belongs in contrib rather than main?

/Simon



-- 
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/87typ95mwt@mocca.josefsson.org

Bug#580221: ITP: python-libssh2 -- python-libssh2 is a python binding for libssh2 library.

[Simon Josefsson]

Frank Lin PIAT fp...@klabs.be writes:

 -
  libssh2 is the thin library implementing client side of SSH2 protocol
  as defined by Internet Drafts SECSH-TRANS, SECSH-USERAUTH,
  SECSH-CONNECTION, SECSH-ARCH, SECSH-FILEXFER, SECSH-DHGEX,
  SECSH-NUMBERS, and SECSH-PUBLICKEY
  .
  This boils down to the regular terminal, scp and SFTP sessions; port
  forwarding; password, key-based and keyboard-interactive
  authentication.
  .
  This package contains the python bindings libssh2. It is a fork and
  rewrite of org.keyphrene.
 -

 Note that the two first paragraph are a pristine copy of libssh2
 description... the I18N teams should appreciate ;)

On the other hand, I don't think the libssh2 description is particularly
useful for a user.  The uppercase acronyms aren't friendly.  How about
something like this:

  libssh2 is a client-side C library implementing the SSH2 protocol
  with support for regular terminal, scp and SFTP sessions; port
  forwarding; password, key-based and keyboard-interactive
  authentication.
  .
  This package contains the python bindings libssh2. It is a fork and
  rewrite of org.keyphrene.

/Simon



-- 
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/87aasf4czv@mocca.josefsson.org

Bug#574159: ITP: msva-ruby -- Cryptographic identity validation agent (Ruby implementation)

[Simon Josefsson]

mike castleman m...@mlcastle.net writes:

 Package: wnpp
 Severity: wishlist
 Owner: mike castleman m...@mlcastle.net

 * Package name: msva-ruby
   Version : 0.1
   Upstream Author : mike castleman m...@mlcastle.net
 * URL : http://github.com/mlc/msva-ruby
 * License : GPL v3
   Programming Lang: Ruby
   Description : Cryptographic identity validation agent (Ruby 
 implementation)

 The Monkeysphere Validation Agent offers a local service for tools to 
 validate certificates (both X.509 and OpenPGP) and other public keys.

 This package contains a ruby implementation of a Monkeysphere
 Validation Agent.

This GPLv3'd code appears to use OpenSSL but the msva-ruby's license
doesn't have any OpenSSL license exception, and without that the two
licenses are incompatible according to the FSF.

/Simon



-- 
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/87ljdrid60@mocca.josefsson.org

Bug#573206: ITP: png++ -- C++ interface to the PNG library

[Simon Josefsson]

Jonas Smedegaard d...@jones.dk writes:

 Package: wnpp
 Severity: wishlist
 Owner: Jonas Smedegaard d...@jones.dk

 * Package name: png++
   Version : 0.2.3
   Upstream Author : Alex Shulgin alex.shul...@gmail.com
 * URL : http://savannah.nongnu.org/projects/pngpp/
 * License : BSD
   Programming Lang: C++
   Description : C++ interface to the PNG library

I suggest to expand the acronym, something like this:

C++ interface to the PNG (Portable Network Graphics) library

 PNG++ aims to provide simple yet powerful C++ interface to libpng, the
 PNG reference implementation library.

And:

PNG++ aims to provide simple yet powerful C++ interface to libpng, the
Portable Network Graphics (PNG) reference implementation library.

/Simon



-- 
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/873a08lfle@mocca.josefsson.org

Bug#572263: ITP: mpdcron -- Call hooks triggered by MPD events

[Simon Josefsson]

Sebastien Delafond s...@debian.org writes:

 Package: wnpp
 Severity: wishlist
 Owner: Sebastien Delafond s...@debian.org

 * Package name: mpdcron
   Version : 0.3
   Upstream Author : Ali Polatel a...@exherbo.org
 * URL : http://alip.github.com/mpdcron/
 * License : GPL-2
   Programming Lang: C
   Description : Call hooks triggered by MPD events

 * Uses mpd's idle mode.
 * Calls hooks depending on the event.
 * Sets special environment variables to pass data to the hooks.
 * Optional support for modules via GModule.
 * Included modules:
   - notification
 + uses notify-send to send notifications.
 + can detect repeated songs.
   - scrobbler
 + uses curl to submit songs to Last.fm or Libre.fm
   - stats
 + module saves song data to a sqlite database
 + supports loving, killing, rating and tagging songs, artists,
   albums and genres.
 + tracks play count of songs, artist, albums and genres.
 + implements a simple server protocol for remote clients to
   receive data.

It would be nice to expand the 'MPD' acronym and/or explain what MPD is.

/Simon



-- 
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/87tysynvs3@mocca.josefsson.org

Bug#534338: ITP: libopenssl-perl -- OpenSSL bindings in perl

[Simon Josefsson]

Daniel Kahn Gillmor d...@fifthhorseman.net writes:

 Re: licensing: the current version doesn't have explicit licensing in
 the source.  I exchanged mails directly with the upstream author, and
 he confirmed that it is licensed under the same terms as perl (GPL or
 Artistic).  The next release will include the license as part of the
 package.

Does that work?  I'd assume you would also need the OpenSSL license
exemption.

/Simon



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

Bug#521433: ITP: globus-openssl -- Globus Toolkit - Openssl Library and Programs

[Simon Josefsson]

Steffen Moeller steffen_moel...@gmx.de writes:

 Package: wnpp
 Severity: wishlist
 Owner: Steffen Moeller steffen_moel...@gmx.de

 * Package name: globus-openssl
 * URL : http://www.globus.org/
 * License : Apache-2.0
   Programming Lang: C/C++
   Description : Globus Toolkit - Openssl Library and Programs

  The Globus Toolkit is an open source software toolkit used for
  building Grid systems and applications. It is being developed by the
  Globus Alliance and many others all over the world. A growing number
  of projects and companies are using the Globus Toolkit to unlock the
  potential of grids for their cause.
  .
  The libglobus-openssl package contains:
  Openssl Library (virtual GPT glue package)

What does this mean?  Is globus-openssl a fork of openssl, or some kind
of meta-package that depends on openssl?  I recall globus using a highly
patched openssl in the past, have this been resolved?

/Simon



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

Bug#499917: ITP: esekeyd -- multimedia keyboard daemon for Linux

[Simon Josefsson]

Krzysztof Burghardt [EMAIL PROTECTED] writes:

 Package: wnpp
 Severity: wishlist
 Owner: Krzysztof Burghardt [EMAIL PROTECTED]

 * Package name: esekeyd
   Version : 1.2.3
   Upstream Author : Krzysztof Burghardt [EMAIL PROTECTED]
 * URL : http://freshmeat.net/projects/esekeyd/

Shouldn't that be the project's homepage?  According to that freshmeat
page, the homepage is: http://www.burghardt.pl/wiki/software/esekeyd

/Simon


 * License : GPL
   Programming Lang: C
   Description : multimedia keyboard daemon for Linux

 ESE Key Daemon is a multimedia keyboard daemon for Linux.  With the 2.6 kernel
 series it can also handle remote controls, as they are presented as keyboards.
 No kernel patch is required. It is a userspace program that pools
 /dev/input/event? interfaces for incoming keyboard key presses.

 -- System Information:
 Debian Release: lenny/sid
   APT prefers unstable
   APT policy: (900, 'unstable'), (1, 'experimental')
 Architecture: i386 (i686)



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

Bug#415040: ITP: krb5dissect - debug tool to display Kerberos credentials

[Simon Josefsson]

Package: wnpp
Severity: wishlist

I have written krb5dissect, a spin-off from Shishi, and I'm working on
packaging it for Debian now.

See http://josefsson.org/krb5dissect/ for more information.

/Simon


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

Bug#394161: ITP: cl-plus-ssl -- A simple Common Lisp interface to OpenSSL

[Simon Josefsson]

Peter Van Eynde [EMAIL PROTECTED] writes:

 * URL : http://common-lisp.net/project/cl-plus-ssl/
 * License : Lisp LGPL
   Programming Lang: Common Lisp
   Description : A simple Common Lisp interface to OpenSSL

Is the Lisp LGPL license compatible with the OpenSSL license?

/Simon


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

Bug#344586: ITP: shishi - free kerberos implementation

[Simon Josefsson]

Package: wnpp
Severity: wishlist

I have been packaging Shishi, and will try to make it acceptable for
sid over the upcoming holiday.

Shishi is a free kerberos implementation.  I'm the upstream author of
it.  Shishi is part of the GNU project.  The license is currently GPL.

The package is available from:

http://josefsson.org/shishi/

Cheers,
Simon


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