Bug#817865: [Letsencrypt-devel] Bug#817865: RFS: acmetool/0.0.49 [ITP] -- automatic certificate acquisition tool for Let's Encrypt

[Peter Colberg]

On Sun, May 15, 2016 at 06:07:30PM +, Mattia Rizzolo wrote:
> Then, uploaded :)

Mattia, Harlan, thank you for the sponsorship!

Peter

Bug#817865: [Letsencrypt-devel] Bug#817865: RFS: acmetool/0.0.49 [ITP] -- automatic certificate acquisition tool for Let's Encrypt

[Peter Colberg]

On Sun, May 15, 2016 at 05:39:31PM +, Mattia Rizzolo wrote:
> On Sun, May 15, 2016 at 01:30:39PM -0400, Peter Colberg wrote:
> > Please try building acmetool commit fb8b2a5, which disables the
> > OCSP test to avoid network access in the build chroot.
> 
> yeah, that one does build.

Please do a "git fetch" and "git reset --hard origin/master" to fix
a search accident. I promise to never overwrite HEAD again :-(

> Given that you seem to be here, maybe you can double check these lintian
> tags?
> 
> W: acmetool: spelling-error-in-readme-debian acme acme (duplicate word) acme

That is a false positive:

# grep '\' debian/README.Debian
d /var/run/acme 0755 acme acme - -

> I: acmetool: spelling-error-in-binary usr/bin/acmetool unkown unknown

I searched for this spelling error before in all of the Golang
packages but could not find it, so it must be in the Go standard
library. I will file an upstream issue with golang/go.

> There is also this one, but my guess is that is'a false positive?
> I: acmetool: spelling-error-in-binary usr/bin/acmetool writeN written

Yes, the trailing capital letter is characteristic of a false positive
that I have seen in other packages before.

> Also, I don't know golang, but does the same hardening stuff that you do
> on C/C++ applies here too?  In that case:
> I: acmetool: hardening-no-pie usr/bin/acmetool
> I: acmetool: hardening-no-bindnow usr/bin/acmetool

This is an ongoing issue, please see the following bugs:

https://bugs.debian.org/821454

https://bugs.debian.org/823014

I plan to upload a new version of acmetool once #823014 is fixed.

> PS: I had already pulled and worked too.  I *think* that since some
> debhelper versions where the -O was internally refactored it's not
> strictly needed anymore to carry on the -O in all the overrides.

I will ask the Debian Go maintainers whether -O--buildsystem=golang
can be dropped safely. In any case, it’s fixed in commit 4244a83,
which is ready for upload.

Regards,
Peter

Bug#817865: [Letsencrypt-devel] Bug#817865: RFS: acmetool/0.0.49 [ITP] -- automatic certificate acquisition tool for Let's Encrypt

[Mattia Rizzolo]

On Sun, May 15, 2016 at 01:30:39PM -0400, Peter Colberg wrote:
> Please try building acmetool commit fb8b2a5, which disables the
> OCSP test to avoid network access in the build chroot.

yeah, that one does build.
Given that you seem to be here, maybe you can double check these lintian
tags?

W: acmetool: spelling-error-in-readme-debian acme acme (duplicate word) acme
I: acmetool: spelling-error-in-binary usr/bin/acmetool unkown unknown

There is also this one, but my guess is that is'a false positive?
I: acmetool: spelling-error-in-binary usr/bin/acmetool writeN written

Also, I don't know golang, but does the same hardening stuff that you do
on C/C++ applies here too?  In that case:
I: acmetool: hardening-no-pie usr/bin/acmetool
I: acmetool: hardening-no-bindnow usr/bin/acmetool


If you prefer otherwise, I can upload with those, though.

PS: I had already pulled and worked too.  I *think* that since some
debhelper versions where the -O was internally refactored it's not
strictly needed anymore to carry on the -O in all the overrides.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#817865: [Letsencrypt-devel] Bug#817865: RFS: acmetool/0.0.49 [ITP] -- automatic certificate acquisition tool for Let's Encrypt

[Ondrej Novy]

Hi,

2016-05-15 19:26 GMT+02:00 Mattia Rizzolo :
>
> I only maintain letsencrypt.sh that doesn't have tests, so I'm not
> really testing it.  I don't know about the other clients.
>

but there are tests:
https://github.com/lukas2511/letsencrypt.sh/blob/master/test.sh :)

-- 
Best regards
 Bc. Ondrej Novy

Email: n...@ondrej.org
GPG: 3D98 3C52 EB85 980C 46A5  6090 3573 1255 9D1E 064B

Bug#817865: [Letsencrypt-devel] Bug#817865: RFS: acmetool/0.0.49 [ITP] -- automatic certificate acquisition tool for Let's Encrypt

[Peter Colberg]

On Sun, May 15, 2016 at 01:30:39PM -0400, Peter Colberg wrote:
> Hi Mattia,
> 
> Please try building acmetool commit fb8b2a5, which disables the
> OCSP test to avoid network access in the build chroot.

Sorry, I pushed too fast, that should be commit 4244a83.

Peter

Bug#817865: [Letsencrypt-devel] Bug#817865: RFS: acmetool/0.0.49 [ITP] -- automatic certificate acquisition tool for Let's Encrypt

[Peter Colberg]

Hi Mattia,

Please try building acmetool commit fb8b2a5, which disables the
OCSP test to avoid network access in the build chroot.

Peter

Bug#817865: [Letsencrypt-devel] Bug#817865: RFS: acmetool/0.0.49 [ITP] -- automatic certificate acquisition tool for Let's Encrypt

[Mattia Rizzolo]

On Sun, May 15, 2016 at 01:14:54PM -0400, Peter Colberg wrote:
> Thanks for catching this. I built the package in an sbuild chroot,
> which by default does not block network connections. The test is
> trying to contact the Let’s Encrypt staging server.

As you probably know that's not allowed :)
Also, FYI, whilst most of Debian's buildd allows network connection,
ubuntu's don't, so your package would have FTBFS there.

> The easiest solution is to disable the test for now, but in the

yes please.

> long term it would be good to package boulder for Debian and use
> it for offline testing.
> 
> How are you currently testing the other Let’s Encrypt clients?
> 
> Would you be interested in packaging boulder together?

I only maintain letsencrypt.sh that doesn't have tests, so I'm not
really testing it.  I don't know about the other clients.

> > In the meantime I did 3 more trivial commits, that I pushed.
> > 
> > (hope you don't mind the extra commits, but imho that's the main
> > advantage of keeping packages in a team, have the team mates being able
> > to do such sillyness! ;))
> 
> Yes, your commits are very welcome.
> 
> Which repository did you push to? master is still at 771996d:
> 
> https://anonscm.debian.org/cgit/letsencrypt/acmetool.git

Turns out I wrote something I didn't do, pushed now.


Please ping once you disabled those tests

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#817865: [Letsencrypt-devel] Bug#817865: RFS: acmetool/0.0.49 [ITP] -- automatic certificate acquisition tool for Let's Encrypt

[Peter Colberg]

Hi Mattia,

On Sun, May 15, 2016 at 03:55:04PM +, Mattia Rizzolo wrote:
> So, I was about to upload, but it failed to build:
> 
>dh_auto_test -O--buildsystem=golang
>   cd obj-x86_64-linux-gnu
>   go test -v github.com/hlandau/acme/acmeapi 
> github.com/hlandau/acme/acmeapi/acmeendpoints 
> github.com/hlandau/acme/acmeapi/acmeutils 
> github.com/hlandau/acme/cmd/acmetool github.com/hlandau/acme/fdb 
> github.com/hlandau/acme/hooks github.com/hlandau/acme/interaction 
> github.com/hlandau/acme/redirector github.com/hlandau/acme/responder 
> github.com/hlandau/acme/solver github.com/hlandau/acme/storage 
> github.com/hlandau/acme/storageops
…
> === RUN   TestOCSP
> --- FAIL: TestOCSP (0.00s)
>   ocsp_test.go:80: ocsp error: Get 
> http://ocsp.staging-x1.letsencrypt.org//MFQwUjBQME4wTDAJBgUrDgMCGgUABBQ55F6w46hhx/o6OXOHa+Yfe32YhgQU+3hPEvlgFYMsnxd/NBmzLjbqQYkCEwD69zi1DRRe9pEhERQvpXm9NBw=:
>  dial tcp: lookup ocsp.staging-x1.letsencrypt.org on [::1]:53: read udp 
> [::1]:39826->[::1]:53: read: connection refused

Thanks for catching this. I built the package in an sbuild chroot,
which by default does not block network connections. The test is
trying to contact the Let’s Encrypt staging server.

The easiest solution is to disable the test for now, but in the
long term it would be good to package boulder for Debian and use
it for offline testing.

How are you currently testing the other Let’s Encrypt clients?

Would you be interested in packaging boulder together?

> In the meantime I did 3 more trivial commits, that I pushed.
> 
> (hope you don't mind the extra commits, but imho that's the main
> advantage of keeping packages in a team, have the team mates being able
> to do such sillyness! ;))

Yes, your commits are very welcome.

Which repository did you push to? master is still at 771996d:

https://anonscm.debian.org/cgit/letsencrypt/acmetool.git

Regards,
Peter

Bug#817865: [Letsencrypt-devel] Bug#817865: RFS: acmetool/0.0.49 [ITP] -- automatic certificate acquisition tool for Let's Encrypt

[Mattia Rizzolo]

control: owner -1 !
control: tag -1 moreinfo

On Sat, May 14, 2016 at 03:23:56PM -0400, Peter Colberg wrote:
> Would you do the honour of uploading acmetool?
> 
>   git clone https://anonscm.debian.org/git/letsencrypt/acmetool.git
>   cd acmetool && pristine-tar checkout ../acmetool_0.0.49.orig.tar.gz
> 
> For verification, these are the current branch heads:
> 
>   git show-ref --heads
>   771996def6abc5fe64718e5a0aedb4c8608a1579 refs/heads/master
>   7ebb219ff2f4fe4cabc603ef2f4e5155b041c772 refs/heads/pristine-tar
>   1d8a3d99536b3472709a4b184afbdc8b10ebc2f6 refs/heads/upstream
> 
> I will push the release tag after the package has been uploaded.

So, I was about to upload, but it failed to build:

   dh_auto_test -O--buildsystem=golang
cd obj-x86_64-linux-gnu
go test -v github.com/hlandau/acme/acmeapi 
github.com/hlandau/acme/acmeapi/acmeendpoints 
github.com/hlandau/acme/acmeapi/acmeutils github.com/hlandau/acme/cmd/acmetool 
github.com/hlandau/acme/fdb github.com/hlandau/acme/hooks 
github.com/hlandau/acme/interaction github.com/hlandau/acme/redirector 
github.com/hlandau/acme/responder github.com/hlandau/acme/solver 
github.com/hlandau/acme/storage github.com/hlandau/acme/storageops
=== RUN   TestAPI
20160515155055 [DEBUG] acme.api: request: 
https://boulder.test/acme/cert/some-certificate
20160515155055 [DEBUG] acme.api: response: &{ 200  0 0 
map[Content-Type:[application/pkix-cert] Link:[; rel="up"]] 
0xc8200bf260 0 [] false map[]  } 
20160515155055 [DEBUG] acme.api: request: https://boulder.test/acme/issuer-cert
20160515155055 [DEBUG] acme.api: response: &{ 200  0 0 
map[Content-Type:[application/pkix-cert] Link:[; rel="up"]] 
0xc8200bf680 0 [] false map[]  } 
20160515155055 [DEBUG] acme.api: request: https://boulder.test/acme/root-cert
20160515155055 [DEBUG] acme.api: response: &{ 200  0 0 
map[Content-Type:[application/pkix-cert] Replay-Nonce:[some-nonce-root]] 
0xc8200bf8e0 0 [] false map[]  } 
20160515155055 [DEBUG] acme.api: request: 
https://boulder.test/acme/authz/some-authz
20160515155055 [DEBUG] acme.api: response: &{ 200  0 0 
map[Content-Type:[application/json]] 0xc8200bfa60 0 [] false map[]  } 

20160515155055 [DEBUG] acme.api: request: 
https://boulder.test/acme/challenge/some-challenge
20160515155055 [DEBUG] acme.api: response: &{ 200  0 0 
map[Content-Type:[application/json]] 0xc8200bfd40 0 [] false map[]  } 

20160515155055 [DEBUG] acme.api: request: https://boulder.test/directory
20160515155055 [DEBUG] acme.api: response: &{ 200  0 0 
map[Content-Type:[application/json] Replay-Nonce:[foo-nonce]] 0xc820138540 0 [] 
false map[]  } 
20160515155055 [DEBUG] acme.api: request: https://boulder.test/acme/new-cert
20160515155055 [DEBUG] acme.api: response: &{ 201  0 0 
map[Location:[https://boulder.test/acme/cert/some-certificate]] 0xc8201390c0 0 
[] false map[]  } 
20160515155055 [DEBUG] acme.api: request: 
https://boulder.test/acme/cert/some-certificate
20160515155055 [DEBUG] acme.api: response: &{ 200  0 0 
map[Content-Type:[application/pkix-cert] Link:[; rel="up"]] 
0xc820139200 0 [] false map[]  } 
20160515155055 [DEBUG] acme.api: request: https://boulder.test/acme/issuer-cert
20160515155055 [DEBUG] acme.api: response: &{ 200  0 0 
map[Content-Type:[application/pkix-cert] Link:[; rel="up"]] 
0xc8201394a0 0 [] false map[]  } 
20160515155055 [DEBUG] acme.api: request: https://boulder.test/acme/root-cert
20160515155055 [DEBUG] acme.api: response: &{ 200  0 0 
map[Content-Type:[application/pkix-cert] Replay-Nonce:[some-nonce-root]] 
0xc820139700 0 [] false map[]  } 
20160515155055 [DEBUG] acme.api: request: https://boulder.test/acme/new-reg
20160515155055 [DEBUG] acme.api: response: &{ 409  0 0 
map[Replay-Nonce:[nonce0] Location:[https://boulder.test/acme/reg/1]] 
0xc8201e4060 0 [] false map[]  } 
20160515155055 [DEBUG] acme.api: request: https://boulder.test/acme/reg/1
20160515155055 [DEBUG] acme.api: response: &{ 200  0 0 
map[Replay-Nonce:[nonce1] Content-Type:[application/json] 
Link:[; rel="terms-of-service"]] 
0xc8201e4880 0 [] false map[]  } 
20160515155055 [DEBUG] acme.api: request: https://boulder.test/acme/reg/1
20160515155055 [DEBUG] acme.api: response: &{ 200  0 0 
map[Replay-Nonce:[nonce2] Content-Type:[application/json] 
Link:[; rel="terms-of-service"]] 
0xc8201e5100 0 [] false map[]  } 
20160515155055 [DEBUG] acme.api: request: https://boulder.test/acme/reg/1
20160515155055 [DEBUG] acme.api: response: &{ 200  0 0 
map[Replay-Nonce:[nonce3] Content-Type:[application/json] 
Link:[; rel="terms-of-service"]] 
0xc8201e5900 0 [] false map[]  } 
20160515155055 [DEBUG] acme.api: request: https://boulder.test/acme/new-authz
20160515155055 [DEBUG] acme.api: response: &{ 201  0 0 
map[Location:[https://boulder.test/acme/authz/1] Replay-Nonce:[nonce4] 
Content-Type:[application/json]] 0xc820208300 0 [] false map[]  } 

20160515155055 [DEBUG] acme.api: request: 
https://boulder.test/acme/challenge/some-challenge2
20160515155055 [DEBUG] acme.api: response: &{ 200  0 0 

Bug#817865: [Letsencrypt-devel] Bug#817865: RFS: acmetool/0.0.49 [ITP] -- automatic certificate acquisition tool for Let's Encrypt

[Peter Colberg]

Hi Harlan,

On Sat, Mar 26, 2016 at 12:06:08AM -0400, Harlan Lieberman-Berg wrote:
> When the blocks are resolved, ping me and I'll definitely take a look.

Thanks to Dmitry Smirnov, all golang dependencies have been uploaded.

The package "acmetool" is ready for sponsorship:

  git clone https://anonscm.debian.org/git/letsencrypt/acmetool.git

  cd acmetool && pristine-tar checkout ../acmetool_0.0.49.orig.tar.gz

For verification, these are the current branch heads:

  git show-ref --heads
  6bf7d3cfb5f5944a93c0d5f6dcf7404246f908aa refs/heads/master
  7ebb219ff2f4fe4cabc603ef2f4e5155b041c772 refs/heads/pristine-tar
  1d8a3d99536b3472709a4b184afbdc8b10ebc2f6 refs/heads/upstream

Regards,
Peter

Bug#817865: [Letsencrypt-devel] Bug#817865: RFS: acmetool/0.0.49 [ITP] -- automatic certificate acquisition tool for Let's Encrypt

[Peter Colberg]

Dear Debian Let's Encrypt team,

I have switched the Maintainer of the acmetool package to Debian
Let's Encrypt and moved the alioth repository. I will ping you
for sponsorship once all golang dependencies have been uploaded.

  git clone https://anonscm.debian.org/git/letsencrypt/acmetool.git

  cd acmetool && pristine-tar checkout ../acmetool_0.0.49.orig.tar.gz

For verification, these are the current branch heads:

  git show-ref --heads
  d73a38a0004972883e7896e1a6826b2d1994f528 refs/heads/master
  7ebb219ff2f4fe4cabc603ef2f4e5155b041c772 refs/heads/pristine-tar
  1d8a3d99536b3472709a4b184afbdc8b10ebc2f6 refs/heads/upstream

Regards,
Peter

Bug#817865: [Letsencrypt-devel] Bug#817865: RFS: acmetool/0.0.49 [ITP] -- automatic certificate acquisition tool for Let's Encrypt

[Harlan Lieberman-Berg]

Peter Colberg  writes:
> Did you find the time to take a brief look at the acmetool package to
> decide whether the Debian Let’s Encrypt team will provide sponsorship?

Hi Peter!

This definitely seems like something that could fit very well under the
Let's Encrypt team's umbrella.  I'd be happy to review it for
sponsorship.

At the moment, though, it seems there are several pending dependencies
that are required first, and I'm less certain that those would be a good
fit for the team -- I think pkg-go is probably a way better home for
them.  (I only know a little bit of go myself!)

When the blocks are resolved, ping me and I'll definitely take a look.

Thanks for your contributions!  Looking forward to working together.

-- 
Harlan Lieberman-Berg
~hlieberman

Bug#817865: [Letsencrypt-devel] Bug#817865: RFS: acmetool/0.0.49 [ITP] -- automatic certificate acquisition tool for Let's Encrypt

[Peter Colberg]

Hi Harlan,

Did you find the time to take a brief look at the acmetool package to
decide whether the Debian Let’s Encrypt team will provide sponsorship?

Regards,
Peter