Paul Wise writes:
> On Wed, Apr 1, 2020 at 6:01 PM vi...@vheuser.com wrote:
>
>> Did the discussion of continuing support for DANE end??
>
> In case I mislead anyone, a clarification:
>
> Debian itself isn't going to actively work on removing support for
> DANE from anything nor removing our
Hi Paul,
I would like to make use of DANE. What software can I use?
Odo
Am 04.04.20 um 09:47 schrieb Elmar Stellnberger:
> Am 02.04.20 um 16:49 schrieb Elmar Stellnberger:
>> Am 02.04.20 um 01:57 schrieb Paul Wise:
>>> On Wed, Apr 1, 2020 at 6:01 PM vi...@vheuser.com wrote:
>>>
Did the
Am 04.04.20 um 09:47 schrieb Elmar Stellnberger:
Am 02.04.20 um 16:49 schrieb Elmar Stellnberger:
Am 02.04.20 um 01:57 schrieb Paul Wise:
On Wed, Apr 1, 2020 at 6:01 PM vi...@vheuser.com wrote:
Did the discussion of continuing support for DANE end??
In case I mislead anyone, a
Hi,
5 avr. 2020 à 12:00 de william.gagn...@gmail.com:
> could you please > remove > me from the debian-security mailing list?
> It's been year (true story) that I'm asking for that, and I don't even know
> how it is possible coming from an IT group .. :D
>
> Please do this ecological
Hello,
could you please *remove *me from the debian-security mailing list?
It's been year (true story) that I'm asking for that, and I don't even know
how it is possible coming from an IT group .. :D
Please do this ecological contribution ..
Regards
Le sam. 4 avr. 2020 à 09:47, Elmar
Am 02.04.20 um 16:49 schrieb Elmar Stellnberger:
Am 02.04.20 um 01:57 schrieb Paul Wise:
On Wed, Apr 1, 2020 at 6:01 PM vi...@vheuser.com wrote:
Did the discussion of continuing support for DANE end??
In case I mislead anyone, a clarification:
Debian itself isn't going to actively work on
Am 04.04.20 um 00:46 schrieb Lee:
On 4/3/20, Elmar Stellnberger wrote:
Encryption can be a source of arbitrary code execution exploits if not
implemented properly. Encrypting DNS would have other application
purposes and makes sense as long as you use a proxy. If you connect
directly hiding
On 4/3/20, Elmar Stellnberger wrote:
>>There are a few reasons why I believe that DANE / TLSA DNS RR answers
>> are quite trustworthy:
Yes, DANE / TLSA DNS RR answers seem trustworthy. What I don't
consider trustworthy is the clear-text traffic between the client and
the DNSSEC enabled
There are a few reasons why I believe that DANE / TLSA DNS RR answers
are quite trustworthy:
* DNS responses are much faster than establishing a TCP connection
(1.5RTT), usually only about 40ms also because DNS servers tend to be
near the user if not provided by the ISP while the server
Am 02.04.20 um 16:55 schrieb Elmar Stellnberger:
Am 02.04.20 um 11:15 schrieb Lewis Yarema:
But we have the atea tool now. Haven't we? You can use it to download
via DNSSEC/DANE. And I believe Elmar is going to continue support for
it. Debian itself can always support DANE as long as there
Am 02.04.20 um 20:50 schrieb Lee:
On 4/1/20, Paul Wise wrote:
On Wed, Apr 1, 2020 at 6:01 PM vince@ wrote:
Did the discussion of continuing support for DANE end??
In case I mislead anyone, a clarification:
Debian itself isn't going to actively work on removing support for
DANE from
On 4/1/20, Paul Wise wrote:
> On Wed, Apr 1, 2020 at 6:01 PM vince@ wrote:
>
>> Did the discussion of continuing support for DANE end??
>
> In case I mislead anyone, a clarification:
>
> Debian itself isn't going to actively work on removing support for
> DANE from anything nor removing our
Hello.
On 2 Apr 2020, at 0:57, Paul Wise wrote:
> Support for DANE is never going to happen for the web (given the
> opinions of the major browser makers) and it could disappear in other
> upstream projects as the popularity of DoH/DoT and other things in the
> DNS space eclipse DANE/DNSSEC.
Am 02.04.20 um 11:15 schrieb Lewis Yarema:
But we have the atea tool now. Haven't we? You can use it to download
via DNSSEC/DANE. And I believe Elmar is going to continue support for
it. Debian itself can always support DANE as long as there are working
DNSSEC impementations. Just provide a TLSA
Am 02.04.20 um 01:57 schrieb Paul Wise:
On Wed, Apr 1, 2020 at 6:01 PM vi...@vheuser.com wrote:
Did the discussion of continuing support for DANE end??
In case I mislead anyone, a clarification:
Debian itself isn't going to actively work on removing support for
DANE from anything nor
But we have the atea tool now. Haven't we? You can use it to download
via DNSSEC/DANE. And I believe Elmar is going to continue support for
it. Debian itself can always support DANE as long as there are working
DNSSEC impementations. Just provide a TLSA record. And I would believe
that to be
On Wed, Apr 1, 2020 at 6:01 PM vi...@vheuser.com wrote:
> Did the discussion of continuing support for DANE end??
In case I mislead anyone, a clarification:
Debian itself isn't going to actively work on removing support for
DANE from anything nor removing our DANE/DNSSEC records.
Support for
Did the discussion of continuing support for DANE end??
Hope its not too late to weigh in here.
Debian is used by a lot of people with differing security needs.
And trust is a difficult thing to come by.
Why would I trust that the Debian security team
is not cooperating with the FBI/CIA to
Am 26.03.20 um 03:50 schrieb Paul Wise:
On Wed, 2020-03-25 at 11:27 +0100, Elmar Stellnberger wrote:
OpenPGP is no solution to the issue.
DANE is not gonna disappear.
I guess we will have to agree to disagree, end of thread for me.
I am far from not having to say more about it.
Am 25.03.20 um 02:50 schrieb Paul Wise:
On Tue, 2020-03-24 at 15:48 +0100, Elmar Stellnberger wrote:
I hope this is gonna happen anytime soon. DANE and thus a valid TLSA
record is of very high value and importance for getting a genuine
download of Debian. As I have mentioned before downloads
On Tue, 2020-03-24 at 15:48 +0100, Elmar Stellnberger wrote:
> I hope this is gonna happen anytime soon. DANE and thus a valid TLSA
> record is of very high value and importance for getting a genuine
> download of Debian. As I have mentioned before downloads via Tor can be
> spoofed like my
Am 24.03.20 um 11:18 schrieb Paul Wise:
On Tue, Mar 24, 2020 at 3:33 AM Paul Wise wrote:
I've forwarded this to the Debian sysadmins IRC channel. I think it is
related to the fact that the cdimage.d.o server is not managed by the
Debian sysadmins, so the UMU ACC admins probably used Lets
On Tue, Mar 24, 2020 at 3:33 AM Paul Wise wrote:
> I've forwarded this to the Debian sysadmins IRC channel. I think it is
> related to the fact that the cdimage.d.o server is not managed by the
> Debian sysadmins, so the UMU ACC admins probably used Lets Encrypt to
> get certs, and then of course
On Mon, Mar 23, 2020 at 4:00 PM Elmar Stellnberger wrote:
> The only site which is still making problems is cdimage.debian.org.
> Could any good Christ from the Debian community have a look at this
> issue. The server maintainers would need to complain about the rogue cert!
I've forwarded this
I have just released a̅tea v0.6: https://www.elstel.org/atea/ . It now
implements SNI (Server Name Indication) and can thus also be
successfully used to download files like my public gpg key from elstel.org.
atea tii-cert -rv https://cdimage.debian.org
TLSA record (first three bytes are for
https://www.elstel.org/Teorema.html.en
Teorema - a modern portuguese short story, freshly translated into
English and German
:: Debianopolis - o povo cristão
Am 04.03.20 um 20:41 schrieb Elmar Stellnberger:
It would be a question if anyone has tried to download a SHA512SUMS file
from
If anyone wants to play with atea use it under GPLv3. I forgot to add
the license header in the file but this email should entitle you to use
the program under GPLv3.
Elmar
Am 04.03.20 um 20:51 schrieb Elmar Stellnberger:
Hint: You can use -v to get a more verbose output if atea fails which
Hint: You can use -v to get a more verbose output if atea fails which
includes the sha256 hash of the certificate (-vv would also be
possible). From version 0.5 on atea should also do it without the
--sys-keyfile option. For me atea succeeds with domains like
mail.dotplex.com,
It would be a question if anyone has tried to download a SHA512SUMS file
from cdimage.debian.org with atea? As it turned out downloading this
file with tails/tor is NOT sufficient. I have verified a Debian Live
10.1.0 DVD image against the Debian 10.1.0 Install BD-DL I have.
Debcheckroot
Hi folks
You can now download the indicated program at
https://www.elstel.org/atea/ and read some documentation at
https://www.elstel.org/DANE/.
Kind Regards,
Elmar
Am 17.01.20 um 16:52 schrieb Elmar Stellnberger:
Hi Cindy Sue! Hi folks!
I must confess there is little you can do
The programs which I use for secure DANE web browsing should be uploaded
at: https://www.elstel.org/DANE/
documentation follows later
Am 17.01.20 um 16:52 schrieb Elmar Stellnberger:
Hi Cindy Sue! Hi folks!
I must confess there is little you can do about missing emails with
debcheckroot.
Hi Cindy Sue! Hi folks!
I must confess there is little you can do about missing emails with
debcheckroot. You can spot rootkits with hindsight but intelligence can
also break in and go without leaving any trace. What would to my mind be
necessary for a more secure email communication is a
On 11/27/19, Elmar Stellnberger wrote:
>
> Am 25.11.19 um 12:35 schrieb Patrick Schleizer:
>> Yes, forget about NSA and alike. Let's not assume quasi-omnipotent
>> attackers. That leads to defeatist mindset which isn't productive.
>
>I would not let myself be defeated easily. Who has thought
Am 25.11.19 um 17:52 schrieb Elmar Stellnberger:
Not using apt/dpkg comes at the expense of not being able to fully
verify the whole system. What if there are outdated packages on the
system which aren't available from anymore from repository? Using
snapshot.debian.org?
I have just extended
Am 25.11.19 um 12:35 schrieb Patrick Schleizer:
Yes, forget about NSA and alike. Let's not assume quasi-omnipotent
attackers. That leads to defeatist mindset which isn't productive.
I would not let myself be defeated easily. Who has thought about
emails in your inbox which are deleted
Am 21.11.19 um 13:59 schrieb Odo Poppinger:
Am 20.11.19 um 12:29 schrieb Elmar Stellnberger:
debcheckroot is targeted at technically experienced users. No way to
hunt rootkits authored by the NSA otherwise. You have to be a tough
user to take this challenge! Well you can of course also use it
Am 25.11.19 um 12:35 schrieb Patrick Schleizer:
How often did you see initrd being infected?
recently only once. So the attackers may change their vector; they have
already done so multiple times.
Not using apt/dpkg comes at the expense of not being able to fully
verify the whole system.
Elmar Stellnberger:
>>> Things debcheckroot does not check at the moment are the initrd and
>> the MBR (master boot record). You may unpack the initrd by hand and
>> check the files contained there against a sha256sum list generated by
>> debcheckroot. The MBR can first be backuped by
Yes, that is a very good idea!:
* debcheckroot with sha256-lists is considerably faster because it does not
need to download and unpack all packages
* unknown/forgotten packages of elder versions could still be checked
because the sha256sums are not forgotten
* You can generate sha256sums
Am 21.11.19 um 13:59 schrieb Odo Poppinger:
Am 20.11.19 um 12:29 schrieb Elmar Stellnberger:
debcheckroot is targeted at technically experienced users. No way to
hunt rootkits authored by the NSA otherwise. You have to be a tough
user to take this challenge! Well you can of course also use it
Am 20.11.19 um 12:29 schrieb Elmar Stellnberger:
debcheckroot is targeted at technically experienced users. No way to hunt
rootkits authored by the NSA otherwise. You have to be a tough user to take
this challenge! Well you can of course also use it for other kinds of
rootkits by other
Am 19.11.19 um 13:29 schrieb Patrick Schleizer:
Anyone using this yet?
I would speculate, not many are using it. It needs step by step
instructions. Otherwise, most users are lost at hello.
Well, I have a couple of downloads every day, the more serious ones with
wget.
Things
Anyone using this yet?
I would speculate, not many are using it. It needs step by step
instructions. Otherwise, most users are lost at hello.
> Things debcheckroot does not check at the moment are the initrd and
the MBR (master boot record). You may unpack the initrd by hand and
check the files
43 matches
Mail list logo
