From fa-ml at ariis.it  Sun Feb  3 21:22:30 2019
From: fa-ml at ariis.it (Francesco Ariis)
Date: Sun, 3 Feb 2019 22:22:30 +0100
Subject: [Patch] Fix estimator explanation
Message-ID: <20190203212229.k4hx27bwtk7puqqk@x60s.casa>

Good evening hackage developers,
    please consider merging this patch to hackage-server.
The rationale (and the patch itself) is very simple: to point to the
more precise (and more clear) documentation for the chosen estimator.
Thanks
-F
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Fix-estimator-explanation.patch
Type: text/x-diff
Size: 1663 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/cabal-devel/attachments/20190203/7f638603/attachment.patch>

From gershomb at gmail.com  Tue Feb  5 21:21:36 2019
From: gershomb at gmail.com (Gershom B)
Date: Tue, 5 Feb 2019 16:21:36 -0500
Subject: [Patch] Fix estimator explanation
In-Reply-To: <20190203212229.k4hx27bwtk7puqqk@x60s.casa>
References: <20190203212229.k4hx27bwtk7puqqk@x60s.casa>
Message-ID: <CAM8RHpH9dPjm3TJrvp2YSmcWEZw2xH6GPtiZROKepaUg+HRQQA@mail.gmail.com>

Sorry for the slow response time. I know you've been on this for a
while. I've now committed those changes to master and they'll be in
the next redeploy. Thanks!

--Gershom

On Sun, Feb 3, 2019 at 4:22 PM Francesco Ariis <fa-ml at ariis.it> wrote:
>
> Good evening hackage developers,
>     please consider merging this patch to hackage-server.
> The rationale (and the patch itself) is very simple: to point to the
> more precise (and more clear) documentation for the chosen estimator.
> Thanks
> -F
> _______________________________________________
> cabal-devel mailing list
> cabal-devel at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel

From fa-ml at ariis.it  Tue Feb  5 21:31:54 2019
From: fa-ml at ariis.it (Francesco Ariis)
Date: Tue, 5 Feb 2019 22:31:54 +0100
Subject: [Patch] Fix estimator explanation
In-Reply-To: <CAM8RHpH9dPjm3TJrvp2YSmcWEZw2xH6GPtiZROKepaUg+HRQQA@mail.gmail.com>
References: <20190203212229.k4hx27bwtk7puqqk@x60s.casa>
 <CAM8RHpH9dPjm3TJrvp2YSmcWEZw2xH6GPtiZROKepaUg+HRQQA@mail.gmail.com>
Message-ID: <20190205213154.r6gd4moyh5uhxqyb@x60s.casa>

On Tue, Feb 05, 2019 at 04:21:36PM -0500, Gershom B wrote:
> Sorry for the slow response time. I know you've been on this for a
> while. I've now committed those changes to master and they'll be in
> the next redeploy. Thanks!

Awesome!
    many thanks Gershom
-F

From gershomb at gmail.com  Sun Feb 17 03:37:02 2019
From: gershomb at gmail.com (Gershom B)
Date: Sat, 16 Feb 2019 22:37:02 -0500
Subject: downloads.haskell.org now moved
Message-ID: <CAM8RHpH7aKfQ2buOxMWt4dNkOEUvjvCbp5+2tPandrXac-RDfg@mail.gmail.com>

The migration of the downloads box to packet is now done.

Rather than uploading to downloads-origin.haskell.org, binaries should
now go to downloads-packet-origin.haskell.org. The former will be
decommissioned soon-ish. This applies for cabal and ghc binaries both.
Login for the `cabal` and `ghc` accounts on the box is sftp-only. Let
me know if there's any problems.

Cheers,
Gershom

From haskell at marcelfourne.de  Tue Feb 19 15:43:04 2019
From: haskell at marcelfourne.de (Marcel =?UTF-8?B?Rm91cm7DqQ==?=)
Date: Tue, 19 Feb 2019 16:43:04 +0100
Subject: Pure Haskell replacement for a dependency package
Message-ID: <20190219164304.5a19b274@deck>

Hello,

hackage-security is using the ed25519 package, which in itself is
wrapper library around a C/Assembly implementation.
I have just released a pure Haskell implementation of that (modulo
slightly different API the same signature bytes), without using C bits
other than the well known integer-gmp. Tests and benchmarks are
included, if you want to see those for yourselves, but the proofs for
timing attack security still need to be written up for
scientific publishing.

Would you as developers of hackage-security / Cabal / stack be
interested in adopting such a replacement? And, if yes, what conditions
would such a library have to fulfill?

Best wishes and thank you all for your work,
Marcel

From rick at rickmurphy.org  Tue Feb 19 21:13:05 2019
From: rick at rickmurphy.org (rick)
Date: Tue, 19 Feb 2019 16:13:05 -0500
Subject: cabal user questions
Message-ID: <6a09d17b-8c96-0e01-82cb-6c6fa9e13fad@rickmurphy.org>

I have some cabal user questions. Should I post them here or on Haskell 
cafe?

-- 
rick


From rick at rickmurphy.org  Wed Feb 20 15:26:54 2019
From: rick at rickmurphy.org (rick)
Date: Wed, 20 Feb 2019 10:26:54 -0500
Subject: installing agda-master with cabal on ubuntu
Message-ID: <ea04f932-8eac-3004-8a36-690e87b7cbaf@rickmurphy.org>

Thanks in advance.

I am updating my install to agda-master using the new cabal commands.

After a github clone, Cabal new-build appears to build without error 
ending in the following :

...
/home/rick/agda-master/src/data/lib/prim/Agda/Primitive/Cubical.agda
setup: filepath wildcard 'doc/user-manual.pdf' does not match any files.

It creates a dist-newstyle folder with build, cache, packagedb, sdist 
and tmp directories.

cabal new-install --lib appears to install without error ending in the 
following :
resolving dependencies ... up to date

However, cabal list --installed does not list Agda and Agda is not 
listed as a package under ~/.cabal/packages or ~/.cabal/lib.

Do I just copy my Agda-2.6.0 directory into ~/.cabal/packages?

I can execute agda interactively, etc. I'd just like to get the 
packaging right.

-- 
rick


From mikhail.glushenkov at gmail.com  Fri Feb 22 12:53:35 2019
From: mikhail.glushenkov at gmail.com (Mikhail Glushenkov)
Date: Fri, 22 Feb 2019 12:53:35 +0000
Subject: Pure Haskell replacement for a dependency package
In-Reply-To: <20190219164304.5a19b274@deck>
References: <20190219164304.5a19b274@deck>
Message-ID: <CA+tcxkD0KE2QfjfmYDj9a4vtQEOUdpg7uxpcDvezFaLaCRvn6g@mail.gmail.com>

Hi Marcel,

On Tue, 19 Feb 2019, 15:43 Marcel Fourné <haskell at marcelfourne.de wrote:
>
> Hello,
>
> hackage-security is using the ed25519 package, which in itself is
> wrapper library around a C/Assembly implementation.
> I have just released a pure Haskell implementation of that (modulo
> slightly different API the same signature bytes), without using C bits
> other than the well known integer-gmp. Tests and benchmarks are
> included, if you want to see those for yourselves, but the proofs for
> timing attack security still need to be written up for
> scientific publishing.
>
> Would you as developers of hackage-security / Cabal / stack be
> interested in adopting such a replacement? And, if yes, what conditions
> would such a library have to fulfill?

If it doesn't result in too much of a slowdown, I think it would make
sense to do this change. I'd recommend making the choice between
ed25519/eccrypto configurable via a flag so that we could compare the
two. I'm cc:ing Edsko, who is the main author of hackage-security.

From mikhail.glushenkov at gmail.com  Fri Feb 22 12:55:03 2019
From: mikhail.glushenkov at gmail.com (Mikhail Glushenkov)
Date: Fri, 22 Feb 2019 12:55:03 +0000
Subject: cabal user questions
In-Reply-To: <6a09d17b-8c96-0e01-82cb-6c6fa9e13fad@rickmurphy.org>
References: <6a09d17b-8c96-0e01-82cb-6c6fa9e13fad@rickmurphy.org>
Message-ID: <CA+tcxkDU1T8ZoSSOBhyFtB0ew9jepYozfQmQXdrNewLc6TsCKw@mail.gmail.com>

Hi,

On Tue, 19 Feb 2019, 21:25 rick <rick at rickmurphy.org wrote:
>
> I have some cabal user questions. Should I post them here or on Haskell
> cafe?

Both are fine, but more people subscribe to haskell-cafe, so your
question will likely be answered sooner.

From haskell at marcelfourne.de  Fri Feb 22 13:44:57 2019
From: haskell at marcelfourne.de (Marcel =?UTF-8?B?Rm91cm7DqQ==?=)
Date: Fri, 22 Feb 2019 14:44:57 +0100
Subject: Pure Haskell replacement for a dependency package
In-Reply-To: <CA+tcxkD0KE2QfjfmYDj9a4vtQEOUdpg7uxpcDvezFaLaCRvn6g@mail.gmail.com>
References: <20190219164304.5a19b274@deck>
 <CA+tcxkD0KE2QfjfmYDj9a4vtQEOUdpg7uxpcDvezFaLaCRvn6g@mail.gmail.com>
Message-ID: <20190222144457.34226d46@deck>

Hello Mikhail,

Am 2019-02-22 um 12:53 schrieb Mikhail Glushenkov:

>> Would you as developers of hackage-security / Cabal / stack be
>> interested in adopting such a replacement? And, if yes, what
>> conditions would such a library have to fulfill?  
>
>If it doesn't result in too much of a slowdown, I think it would make
>sense to do this change. I'd recommend making the choice between
>ed25519/eccrypto configurable via a flag so that we could compare the
>two. I'm cc:ing Edsko, who is the main author of hackage-security.

That sounds prudent. 
I included some basic benchmarks and depending on the CPU used I get
some triple digit signatures/verifications per second per core (even on
Sandy Bridge; only low-hanging fruit optimizations used until now).
ed25519 is faster, but I am unsure what your intended performance
profile is.

From mikhail.glushenkov at gmail.com  Fri Feb 22 13:46:34 2019
From: mikhail.glushenkov at gmail.com (Mikhail Glushenkov)
Date: Fri, 22 Feb 2019 13:46:34 +0000
Subject: Pure Haskell replacement for a dependency package
In-Reply-To: <CA+tcxkD0KE2QfjfmYDj9a4vtQEOUdpg7uxpcDvezFaLaCRvn6g@mail.gmail.com>
References: <20190219164304.5a19b274@deck>
 <CA+tcxkD0KE2QfjfmYDj9a4vtQEOUdpg7uxpcDvezFaLaCRvn6g@mail.gmail.com>
Message-ID: <CA+tcxkARW1+9HUkGEq+=zPVYMRDuddcZm0riuf593LvAspDX0Q@mail.gmail.com>

Hi,

On Fri, 22 Feb 2019 at 12:53, Mikhail Glushenkov
<mikhail.glushenkov at gmail.com> wrote:
>
> If it doesn't result in too much of a slowdown, I think it would make
> sense to do this change. I'd recommend making the choice between
> ed25519/eccrypto configurable via a flag so that we could compare the
> two. I'm cc:ing Edsko, who is the main author of hackage-security.

Looking closer at eccrypto, I can identify the following issues:

1) eccrypto has a larger dependency footprint than ed25519, which only
depends on GHC boot libraries
2) ed25519 is much better documented
3) eccrypto is quite new and not as mature as ed25519, which is based
on the reference implementation

However, I still think that we could accept a patch adding support for
eccrypto as a compile-time option (not enabled by default).

From haskell at marcelfourne.de  Thu Feb 28 17:14:11 2019
From: haskell at marcelfourne.de (Marcel =?UTF-8?B?Rm91cm7DqQ==?=)
Date: Thu, 28 Feb 2019 18:14:11 +0100
Subject: Pure Haskell replacement for a dependency package
In-Reply-To: <CA+tcxkARW1+9HUkGEq+=zPVYMRDuddcZm0riuf593LvAspDX0Q@mail.gmail.com>
References: <20190219164304.5a19b274@deck>
 <CA+tcxkD0KE2QfjfmYDj9a4vtQEOUdpg7uxpcDvezFaLaCRvn6g@mail.gmail.com>
 <CA+tcxkARW1+9HUkGEq+=zPVYMRDuddcZm0riuf593LvAspDX0Q@mail.gmail.com>
Message-ID: <20190228181411.38680f53@rechner>

Hi,

Am 2019-02-22 um 13:46 schrieb Mikhail Glushenkov:
>Looking closer at eccrypto, I can identify the following issues:
>
>1) eccrypto has a larger dependency footprint than ed25519, which only
>depends on GHC boot libraries
>2) ed25519 is much better documented
>3) eccrypto is quite new and not as mature as ed25519, which is based
>on the reference implementation

Regarding those issues, I uploaded a new version of eccrypto with only
cryptohash-sha512 as a non-boot dependency. Since hackage-security
already depends on cryptohash-sha256 with its low depency footprint, I
thought it most prudent to go that route. Of course, the new code is
also analysed like the one from last release.
Documentation will follow, as well as scientific review.
Only the last part - being more mature than the ref10 C code - my code
will never be. ;-)


>However, I still think that we could accept a patch adding support for
>eccrypto as a compile-time option (not enabled by default).

I'll also start looking into making a patch for hackage-security
for review.

Best,
Marcel