Hey all,
I'm reading to upload a new package called SQLCipher
(http://sqlcipher.net/) and I want to run it by y'all first. The upside
is that it provides AES256 encrypted SQLite databases in a DFSG-free
package that has been pretty widely tested, deployed and audited. You
can find out more
On 09/28/2012 04:23 PM, Florian Weimer wrote:
* Hans-Christoph Steiner:
The tricky part is that it is a modified version of SQLite3, and lintian
properly gives an error about that. But because of the features that
SQLCipher provides, it must modify the core of SQLite to work, therefore
On 10/01/2012 06:32 PM, Stephen Lombardo wrote:
Hello Florian,
On Mon, Oct 1, 2012 at 1:57 PM, Florian Weimer f...@deneb.enyo.de wrote:
Okay. Can your fork open unencrypted databases? Are there any symbol
collisions with vanilla SQLite?
Yes, SQLCipher can open standard, unencrypted SQLite
On Oct 1, 2012, at 7:36 PM, Hans-Christoph Steiner wrote:
On 10/01/2012 06:32 PM, Stephen Lombardo wrote:
Hello Florian,
On Mon, Oct 1, 2012 at 1:57 PM, Florian Weimer f...@deneb.enyo.de wrote:
Okay. Can your fork open unencrypted databases? Are there any symbol
collisions with vanilla
On Oct 12, 2012, at 9:03 PM, Hans-Christoph Steiner wrote:
On Oct 1, 2012, at 7:36 PM, Hans-Christoph Steiner wrote:
On 10/01/2012 06:32 PM, Stephen Lombardo wrote:
Hello Florian,
On Mon, Oct 1, 2012 at 1:57 PM, Florian Weimer f...@deneb.enyo.de wrote:
Okay. Can your fork open
I want to run an unusual idea by everyone here as an approach to getting an
outside signature into a packaged Java jar built from source on the Debian
build machines: we want to get http://martus.org packaged and into Debian.
Martus is an app that has high requirements for security, so they have a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 08/29/2013 10:56 AM, Michael Stone wrote:
On Thu, Aug 29, 2013 at 11:35:47AM +0200, Sébastien Le Ray wrote:
Yes but the whole thing looks weird, on one hand OP wants to include a
signed jar in the package, on the other hand he says signature
On 10/30/2013 10:49 AM, Norbert Kiszka wrote:
Dnia 2013-10-30, śro o godzinie 11:34 -0200, Djones Boni pisze:
On 30-10-2013 11:05, Celejar wrote:
You're snipping crucial context; my comment above was in response to
this:
For apt-get a self-signed certificate could be used which comes together
On 11/11/2013 07:41 PM, Jérémie Marguerie wrote:
On Mon, Nov 11, 2013 at 2:48 PM, Mike Mestnik che...@mikemestnik.net wrote:
I don't see how this is relevant? Obviously if hardware is seized then the
owners no longer have control. If you have suggestions as to how to secure
hardware that's
inside the device once/if compromised?
2013/11/12 Andreas Kuckartz a.kucka...@ping.de
Hans-Christoph Steiner:
The crypto smartcard (aka Hardware Security Module) are some work to
setup,
but not really all that much. And they are easy to use once setup. And
they
provide a huge boost
On 11/12/2013 01:58 PM, Henrik Ahlgren wrote:
On Tue, Nov 12, 2013 at 01:15:38PM -0500, Hans-Christoph Steiner wrote:
Having the key generated on the card is the most secure, since those cards
are
designed so you can't read the secret key off of the card. So the cost of
putting a new
On 01/20/2014 12:22 PM, Octavio Alvarez wrote:
On 01/20/2014 05:29 AM, Marco Saller wrote:
I have read that the NSA proposed to include SELinux in linux 2.5. (Linux
Kernel Summit 2001)
Don't you think that may be one of their fancy tricks to gain access to
computers running linux? Some
On 01/26/2014 01:30 PM, Andrew McGlashan wrote:
On 25/01/2014 7:39 PM, Emmanuel Thierry wrote:
Then DNSSEC appeared ! :)
I wish it was that simple I don't believe it is today, but one day
it will have to be the standard.
I remind you it is really difficult to compromise DNS zones
On May 30, 2014, at 2:41 PM, W. Martin Borgert wrote:
Quoting Jeremie Marguerie jere...@marguerie.org:
Thanks for bringing that issue! I feel the same way when I install a
packet from a non-official PPA.
Unfortunately, every package can do anything: pre-inst, post-inst,
pre-rm, post-rm
On May 30, 2014, at 10:06 AM, micah anderson wrote:
Kurt Roeckx k...@roeckx.be writes:
On Fri, May 30, 2014 at 10:43:56PM +1000, Alfie John wrote:
On Fri, May 30, 2014, at 10:24 PM, Michael Stone wrote:
On Fri, May 30, 2014 at 10:15:01PM +1000, Alfie John wrote:
The public Debian mirrors
On Jun 2, 2014, at 9:29 AM, Jann Horn wrote:
On Fri, May 30, 2014 at 10:06:06AM -0400, micah anderson wrote:
Now I don't want to call into question the esteemed authors of said
program, and depending libraries, but I do think that providing https
mirrors gives us two distinct advantages over
On Jul 3, 2014, at 11:05 AM, Hans-Christoph Steiner wrote:
On May 30, 2014, at 10:06 AM, micah anderson wrote:
Kurt Roeckx k...@roeckx.be writes:
On Fri, May 30, 2014 at 10:43:56PM +1000, Alfie John wrote:
On Fri, May 30, 2014, at 10:24 PM, Michael Stone wrote:
On Fri, May 30, 2014
On Jul 3, 2014, at 11:55 AM, Reid Sutherland wrote:
On Jul 3, 2014, at 11:09 AM, Hans-Christoph Steiner h...@at.or.at wrote:
On Jun 2, 2014, at 9:29 AM, Jann Horn wrote:
On Fri, May 30, 2014 at 10:06:06AM -0400, micah anderson wrote:
Now I don't want to call into question the esteemed
On Jul 3, 2014, at 11:52 AM, Michael Stone wrote:
On Thu, Jul 03, 2014 at 11:05:17AM -0400, Hans-Christoph Steiner wrote:
I definitely agree there are legitimate concerns that using HTTPS on apt
mirrors would help, and people who suggest otherwise are out of date on what
the threats
On Jul 3, 2014, at 12:10 PM, Hans-Christoph Steiner wrote:
On Jul 3, 2014, at 11:52 AM, Michael Stone wrote:
On Thu, Jul 03, 2014 at 11:05:17AM -0400, Hans-Christoph Steiner wrote:
I definitely agree there are legitimate concerns that using HTTPS on apt
mirrors would help, and people
On 07/03/2014 12:38 PM, Reid Sutherland wrote:
On Jul 3, 2014, at 12:25 PM, Hans-Christoph Steiner h...@at.or.at wrote:
As for how to manage making HTTPS by default, this does not require every
mirror buying HTTPS certificates every year from Certificate Authorities.
There are workable
On 07/03/2014 12:58 PM, Reid Sutherland wrote:
On Jul 3, 2014, at 12:46 PM, Hans-Christoph Steiner h...@at.or.at wrote:
SSH uses entirely unsigned keys, and it has proven a lot more reliable than
HTTPS/TLS. You use HTTPS/TLS keys the same way as SSH, but TLS requires
signed keys, self
On 07/03/2014 03:08 PM, Michael Stone wrote:
On Thu, Jul 03, 2014 at 12:46:45PM -0400, Hans-Christoph Steiner wrote:
Google uses SPKI pinning heavily, for example,
but they still use CA-signed certificates so their HTTPS works with Firefox,
IE, Opera, etc.
Yes, and MS does similar
On 07/03/2014 02:26 PM, Bernhard R. Link wrote:
* Hans-Christoph Steiner h...@at.or.at [140703 18:10]:
You are correct that HTTPS would not entirely address #2, but it does
improve the situation over HTTP. For example, an ISP, network operator,
or government could block an entire mirror
After the latest revelation about NSA tracking all Tor downloads[1] (with
source code!) and the whole Debian mirrors and MITM redux, I think we should
start talking about concrete steps that we can take to improve the situation.
The first things that came to mind would be quite easy to do:
*
On 07/04/2014 11:43 AM, Lou RUPPERT wrote:
Joel Rees:
On Fri, Jul 4, 2014 at 11:44 AM, Hans-Christoph Steiner
h...@at.or.at wrote:
[rhetoric encouraging the use of TLS transport for mirrors] [list
of current https mirrors]
Far be it from me to argue with ucalgary.ca, but one thing
On 07/06/2014 10:20 PM, Michael Stone wrote:
On Sat, Jul 05, 2014 at 08:54:55AM +0900, Joel Rees wrote:
And you know, the funny thing is that MSIE took to warning people
when there was a mix of encrypted and unencrypted data on a page. How
long ago? Yeah, I know, it was so they could display
On 07/06/2014 10:31 PM, Lou RUPPERT wrote:
Joel Rees:
On Sat, Jul 5, 2014 at 12:43 AM, Lou RUPPERT
hims...@louruppert.com wrote:
As someone pointed out, verifying the mirror we've connected to is
not useful when we don't particularly have, or want, a way to
prevent a spook-owned mirror
On 07/07/2014 06:43 PM, Jeremie Marguerie wrote:
On Mon, Jul 7, 2014 at 3:15 PM, Lou RUPPERT hims...@louruppert.com wrote:
If I'm looking at a catalog page from a shoe store on my table,
connected via the phone network, getting close to my 2G cap for my
wireless router for the month. My
certificate authorities and which ones are
cooperating with the NSA?
So how can we really be sure that our Debian install has not been
compromised from the beginning?
On Thu, Jul 3, 2014 at 8:44 PM, Hans-Christoph Steiner h...@at.or.at
wrote:
After the latest revelation
On 07/14/2014 12:31 PM, Paul Wise wrote:
On Tue, Jul 15, 2014 at 12:24 AM, Hans-Christoph Steiner wrote:
I agree that .deb packages should be individually signed
...
This has been discussed in the past. I really think it is just a
matter of someone doing the work.
The work has been
On 07/14/2014 12:59 PM, Paul Wise wrote:
On Tue, Jul 15, 2014 at 12:45 AM, Hans-Christoph Steiner wrote:
I'd like to contribute to this effort
First thing is to get #733029 fixed, which involves disabling signing
by default (signing should be done after testing not before) and
adding
On 07/14/2014 01:12 PM, Michael Stone wrote:
On Mon, Jul 14, 2014 at 12:45:38PM -0400, Hans-Christoph Steiner wrote:
One place that this will help a lot is managing completely offline machines,
like machines for running secure build and signing processes. Right now, in
order to install
On 07/14/2014 01:57 PM, Michael Stone wrote:
On Mon, Jul 14, 2014 at 01:22:10PM -0400, Hans-Christoph Steiner wrote:
Or, you could make use of the Check-Valid-Until and Min-ValidTime options in
apt.conf. There's a reason things are done the way they are, and you
probably
aren't going
On 07/15/2014 02:11 PM, Michael Stone wrote:
On Tue, Jul 15, 2014 at 01:28:08PM -0400, Hans-Christoph Steiner wrote:
How do you propose managing a distro that mostly needs apt as is, but other
times need Acquire::Check-Valid-Until off;? In other words, how would you
manage a distro
On 07/16/2014 08:06 AM, Holger Levsen wrote:
Hi,
On Mittwoch, 16. Juli 2014, Michael Stone wrote:
Yes you are--what you described is exactly how the Release files work.
Well, there are (many) other .debs on the net which are not part of our
releases, so it still seems to me that making
On 07/17/2014 08:20 AM, Joel Rees wrote:
A little context?
On Thu, Jul 17, 2014 at 1:26 AM, Hans-Christoph Steiner h...@at.or.at wrote:
[...]
* TAILS is a Debian-based live CD
* the core system image by definition cannot be modified (live CD)
* it has a feature for persistent storage
Holger Levsen wrote:
Hi Hans,
On Mittwoch, 16. Juli 2014, Hans-Christoph Steiner wrote:
What I'm talking about already exists in Debian, but is rarely used.
dpkg-sig creates a signature that is embedded in the .deb file. So that
means no matter how the .deb file got onto a system
Daniel Kahn Gillmor wrote:
Thanks for the discussion, Hans.
On 09/19/2014 02:47 PM, Hans-Christoph Steiner wrote:
Packages should not be accepted into any official repo, sid included, without
some verification builds. A .deb should remain unchanged once it is accepted
into any official
W. Martin Borgert wrote:
On 2014-09-24 23:05, Hans-Christoph Steiner wrote:
* the signature files sign the package contents, not the hash of
whole .deb file (i.e. control.tar.gz and data.tar.gz).
So preinst and friends would not be signed? Sounds dangerous to me.
All package contents
René Mayrhofer wrote:
On 2014-09-25 06:24, Hans-Christoph Steiner wrote:
W. Martin Borgert wrote:
On 2014-09-24 23:05, Hans-Christoph Steiner wrote:
* the signature files sign the package contents, not the hash of
whole .deb file (i.e. control.tar.gz and data.tar.gz).
So preinst
:
* mostly various user utilities
* no setuid or special permissions
* only one daemon-like thing, adb, with no net access by default
* a good chunk is just files on the filesystem (e.g. libs for Android apps)
.hc
Hans-Christoph Steiner:
>
> BoringSSL is just a part of the Android SDK.
BoringSSL is just a part of the Android SDK. It has an unstable API
because it is only the C backing to a single Java library called
conscrypt. That library is in turn only used as part of the Android
SDK. Using the upstream build system, all of the source code is checked
out at once from many
Patrick Schleizer:
> Julian Andres Klode:
>> (2) look at the InRelease file and see if it contains crap
>> after you updated (if it looks OK, it's secure - you need
>> fairly long lines to be able to break this)
>
> Thank you for that hint, Julian!
>
> Can you please elaborate on this?
Hans-Christoph Steiner:
>
>
> Peter Lawler:
>>
>>
>> On 18/12/16 22:03, Christoph Moench-Tegeder wrote:
>>> second point requires a lot of work
>>> to resolve.
>>>
>>> Regards,
>>> Christoph
>>>
>>
>>
Peter Lawler:
>
>
> On 18/12/16 22:03, Christoph Moench-Tegeder wrote:
>> second point requires a lot of work
>> to resolve.
>>
>> Regards,
>> Christoph
>>
>
> Monday morning yet-to-be-caffienated thoughts...
>
> I'm going to ignore the 'inconvenience' because I think in this case
> that's a
Seems like a decent idea for this, if other packages need an insecure
openssl. As for making it hard to link to, the .so can be put into a
non-standard dir so it has to be explicitly enabled both with a
-lcrypto-insecure and -L/usr/lib/openssl-insecure.
.hc
Jonathan Yu:
> Given that this would
Ansgar Burchardt:
> Henrique de Moraes Holschuh writes:
>> On Fri, 27 Oct 2017, Hans-Christoph Steiner wrote:
>>> This idea that GPG signatures on the index files is enough has been
>>> totally disproven. There was a bug in apt where Debian devices could be
>>&g
Christoph Biedl:
> 林博仁 wrote...
>
>> I believe that there's no benefit on accessing Debian archive with HTTPS as
>> they uses GnuPG for authentication
>
> GnuPG indeed serves the purposes of authenticity and integrity very
> well. Modulo bugs every now and then, but they happen on other layers
FYI, I wrote a script to check the amd64 packages against the published
hash, if anyone wants to use it, it is attached.
.hc
Evgeny Kapun:
> On 22.01.2019 16:59, Vladislav Kurz wrote:
>> Hello everybody,
>>
>> is this vulnerability affecting also apt-get ?
>
> Yes, the vulnerability is in http
50 matches
Mail list logo
