Shouldn't a decent OS scrub RAM and disk sectors before allocating them to
processes, unless that process enters processor privileged mode and sets a call
flag? I recall digging through disk sectors on RSTS/E to look for passwords and
other interesting stuff over 30 years ago.
matthew black
cal
Le 2014-04-14 10:38, Matthew Black a écrit :
> Shouldn't a decent OS scrub RAM and disk sectors before allocating them to
> processes, unless that process enters processor privileged mode and sets a
> call flag? I recall digging through disk sectors on RSTS/E to look for
> passwords and other in
Also on this same idea, in his book "The Puzzle Palace," James Bamford claims
that we knew of the pending attack on Pearl Harbor but did nothing, because
that would compromise we broke the Japanese Purple Cipher.
matthew black
california state university, long beach
-Original Message-
I applaud their effort but please see
https://blogs.akamai.com/2014/04/heartbleed-update-v3.html
&
http://lekkertech.net/akamai.txt
Kind regards / Vriendelijke groet,
IS Group
Thijs Stuurman
-Oorspronkelijk bericht-
Van: Niels Bakker [mailto:niels=na...@bakker.net]
Verzonden: Sunda
Matthew,
On Mon, Apr 14, 2014 at 10:48 AM, Matthew Black wrote:
> Also on this same idea, in his book "The Puzzle Palace," James Bamford
> claims that we knew of the pending attack on Pearl Harbor but did nothing,
> because that would compromise we broke the Japanese Purple Cipher.
I assume you
On Apr 13, 2014, at 7:52 AM, Randy Bush wrote:
>>> the point of open source is that the community is supposed to be doing
>>> this. we failed.
>> Versus all of the closed source bugs that nobody can know of or do
>> anything about?
>
> for those you can blame the vendor. this one is owned by
Just a thought. I keep thinking that Yahoo's publishing of their
"p=reject" policy, and the subsequent massive denial of service to lost
of list traffic might be viewed as a "computer security" incident.
Anybody think that reporting via CERT channels might be an appropriate
response?
(I do,
Yes Matthew it should. The question is whether they do or not.
Todd
On 4/14/2014 7:38 AM, Matthew Black wrote:
Shouldn't a decent OS scrub RAM and disk sectors before allocating them to
processes, unless that process enters processor privileged mode and sets a call
flag? I recall digging thro
Vladis is %100 on the money here. Lets take this a step farther and ask
is there a criminal liability for the person who checked that code in -
Oh you bet there is...
Todd
On 4/11/2014 5:49 PM, valdis.kletni...@vt.edu wrote:
On Sat, 12 Apr 2014 07:56:01 +1000, Matt Palmer said:
The interest
On Mon, Apr 14, 2014 at 9:27 AM, TGLASSEY wrote:
> Vladis is %100 on the money here. Lets take this a step farther and ask is
> there a criminal liability for the person who checked that code in - Oh you
> bet there is...
>
> Todd
Thank you--I needed some humour in my
morning, I was starting to
I don't see what the big deal is here. They don't want your messages and they
made that clear. Their policy considers these messages spam. If you really
want to get your mailing list messages through, then you need to evade their
filters just like every other spammer has to.
-Laszlo
On Apr
On Mon, 14 Apr 2014 16:56:46 -, Laszlo Hanyecz said:
> If you really want to get your mailing list messages through,
The problem isn't the rest of us trying to mail to Yahoo.
The problem is when Yahoo users post to lists that use DMARC, and the
result is the yahoo user's mail getting bounce
Isn't it the other way around? They don't want their users to be able
to send to mailing lists. They receive traffic from the lists just
fine. Their policy considers only effects mail originating from their
users. Yahoo subscribers can receive messages form nanog just fine, but
they can't s
By their statement it's obvious that yahoo doesn't care about what they broke.
It's unfortunate that email has become so centralized that one entity can cause
so much 'trouble'. Maybe it's a good opportunity to encourage the affected
mailing list subscribers to use their own domains for email,
On Mon, Apr 14, 2014 at 1:03 PM, wrote:
> The problem is when Yahoo users post to lists that use DMARC, and the
> result is the yahoo user's mail getting bounced or dumped on the postmaster.
Basically, this is just like old ORBS. If you were an ISP, you had to
check your local users' IP addresse
On Mon, Apr 14, 2014 at 1:25 PM, Laszlo Hanyecz wrote:
> By their statement it's obvious that yahoo doesn't care about what they
> broke. It's
> unfortunate that email has become so centralized that one entity can cause so
> much 'trouble'. Maybe it's a good opportunity to encourage the affecte
On Mon, Apr 14, 2014 at 10:25 AM, Laszlo Hanyecz wrote:
> By their statement it's obvious that yahoo doesn't care about what they
> broke. It's unfortunate that email has become so centralized that one
> entity can cause so much 'trouble'. Maybe it's a good opportunity to
> encourage the affecte
Christopher Morrow wrote:
On Mon, Apr 14, 2014 at 1:25 PM, Laszlo Hanyecz wrote:
By their statement it's obvious that yahoo doesn't care about what they broke.
It's
unfortunate that email has become so centralized that one entity can cause so
much 'trouble'. Maybe it's a good opportunity to
On Mon, Apr 14, 2014 at 1:33 PM, Matthew Petach wrote:
>
> So, I take it you prefer a world in which there's no sender
> validation, and receiving floods of spoofed sender email
> spam is just part of the price of being on the internet?
That is clearly not what this issue is about.
> I'm finding
On Sun, Apr 13, 2014 at 9:52 AM, Niels Bakker wrote:
> At least one vendor, Akamai is helping out now:
> http://marc.info/?l=openssl-users&m=139723710923076&w=2
> I hope other vendors will follow suit.
Although it appears they may now be regretting doing so...
http://www.techworld.com.au/articl
On Apr 14, 2014, at 15:47 , Scott Howard wrote:
> On Sun, Apr 13, 2014 at 9:52 AM, Niels Bakker wrote:
>> At least one vendor, Akamai is helping out now:
>> http://marc.info/?l=openssl-users&m=139723710923076&w=2
>> I hope other vendors will follow suit.
>
>
> Although it appears they may now
On Mon, Apr 14, 2014 at 3:59 PM, Patrick W. Gilmore wrote:
> I applaud Akamai for trying, for being courageous enough to post
> code, and for bucking the trend so many other companies are
> following by being more secretive every year.
>
> Or we can flame anyone who tries, then wonder why no one i
On 04/14/2014 12:59 PM, Patrick W. Gilmore wrote:
On Apr 14, 2014, at 15:47 , Scott Howard wrote:
On Sun, Apr 13, 2014 at 9:52 AM, Niels Bakker wrote:
At least one vendor, Akamai is helping out now:
http://marc.info/?l=openssl-users&m=139723710923076&w=2
I hope other vendors will follow sui
On Mon, Apr 14, 2014 at 11:24 AM, Jim Popovitch wrote:
> DMARC hasn't cut down on yahoo spam so far. Yahoo's spam problem was
> (is?) centered on account hijacks.
>
I just checked my spam folder for the past month.
Out of about 80 messages "from" Yahoo, I can see about 3 that went via
Yahoo's
On Mon, Apr 14, 2014 at 4:10 PM, Scott Howard wrote:
> Whilst I don't agree with the way that Yahoo has done this (particularly
> around communication),
how could they have communicated this better? how can we all learn from this?
-chris
On Mon, Apr 14, 2014 at 03:59:21PM -0400, Patrick W. Gilmore wrote:
> On Apr 14, 2014, at 15:47 , Scott Howard wrote:
> > On Sun, Apr 13, 2014 at 9:52 AM, Niels Bakker
> > wrote:
>
> >> At least one vendor, Akamai is helping out now:
> >> http://marc.info/?l=openssl-users&m=139723710923076&w=2
On 04/14/2014 01:20 PM, Christopher Morrow wrote:
On Mon, Apr 14, 2014 at 4:10 PM, Scott Howard wrote:
Whilst I don't agree with the way that Yahoo has done this (particularly
around communication),
how could they have communicated this better? how can we all learn from this?
The obvious on
On Mon, Apr 14, 2014 at 10:20 PM, Christopher Morrow <
morrowc.li...@gmail.com> wrote:
> On Mon, Apr 14, 2014 at 4:10 PM, Scott Howard wrote:
> > Whilst I don't agree with the way that Yahoo has done this (particularly
> > around communication),
>
> how could they have communicated this better? h
On Mon, Apr 14, 2014 at 4:28 PM, Doug Barton wrote:
> The obvious ones would have been to announce a flag day somewhere far enough
> in advance to give list software devs time to adapt, and to work with list
> software devs on a solution.
where would they communicate this?
on the blog that matt p
On Mon, Apr 14, 2014 at 4:34 PM, Matthias Leisi wrote:
> They could have communicated, as in "listen folks, we are going to make a
> critical change that will affect mailing lists (etc...) in four weeks time".
communicated it where?
> They could have made the change not late on a Friday afternoo
On Mon, Apr 14, 2014 at 4:38 PM, Christopher Morrow
wrote:
> On Mon, Apr 14, 2014 at 4:28 PM, Doug Barton wrote:
>> The obvious ones would have been to announce a flag day somewhere far enough
>> in advance to give list software devs time to adapt, and to work with list
>> software devs on a solu
On Mon, Apr 14, 2014 at 1:39 PM, Christopher Morrow wrote:
> On Mon, Apr 14, 2014 at 4:34 PM, Matthias Leisi
> wrote:
> > They could have communicated, as in "listen folks, we are going to make a
> > critical change that will affect mailing lists (etc...) in four weeks
> time".
>
> communicated
On 04/14/2014 01:38 PM, Christopher Morrow wrote:
On Mon, Apr 14, 2014 at 4:28 PM, Doug Barton wrote:
The obvious ones would have been to announce a flag day somewhere far enough
in advance to give list software devs time to adapt, and to work with list
software devs on a solution.
where woul
On Mon, Apr 14, 2014 at 4:39 PM, Christopher Morrow
wrote:
> On Mon, Apr 14, 2014 at 4:34 PM, Matthias Leisi wrote:
>> They could have communicated, as in "listen folks, we are going to make a
>> critical change that will affect mailing lists (etc...) in four weeks time".
>
> communicated it wher
On Mon, Apr 14, 2014 at 4:44 PM, Scott Howard wrote:
> On Mon, Apr 14, 2014 at 1:39 PM, Christopher Morrow
> wrote:
>>
>> On Mon, Apr 14, 2014 at 4:34 PM, Matthias Leisi
>> wrote:
>> > They could have communicated, as in "listen folks, we are going to make
>> > a
>> > critical change that will a
On Mon, Apr 14, 2014 at 4:44 PM, Doug Barton wrote:
> On 04/14/2014 01:38 PM, Christopher Morrow wrote:
>>
>> On Mon, Apr 14, 2014 at 4:28 PM, Doug Barton wrote:
>>>
>>> The obvious ones would have been to announce a flag day somewhere far
>>> enough
>>> in advance to give list software devs time
On Mon, Apr 14, 2014 at 10:33:40AM -0700, Matthew Petach wrote:
> So, I take it you prefer a world in which there's no sender
> validation, and receiving floods of spoofed sender email
> spam is just part of the price of being on the internet?
Sender validation means NOTHING in a world with hundre
On Mon, Apr 14, 2014 at 12:59 PM, Patrick W. Gilmore
wrote:
I applaud Akamai for trying, for being courageous enough to post code, and
> for bucking the trend so many other companies are following by being more
> secretive every year.
>
Just to be clear, so do I! As I said, the end result was n
On Mon, Apr 14, 2014 at 4:52 PM, Christopher Morrow
wrote:
>
> if you're going to do something that has the potential to affect (say,
> for example) email to a wide set of people, most of which are NOT your
> direct users, how do you go about making that public?
>
> 'the internet' isn't really a g
Matthias Leisi wrote:
On Mon, Apr 14, 2014 at 10:20 PM, Christopher Morrow <
morrowc.li...@gmail.com> wrote:
On Mon, Apr 14, 2014 at 4:10 PM, Scott Howard wrote:
Whilst I don't agree with the way that Yahoo has done this (particularly
around communication),
how could they have communicated t
Christopher Morrow wrote:
On Mon, Apr 14, 2014 at 4:44 PM, Scott Howard wrote:
On Mon, Apr 14, 2014 at 1:39 PM, Christopher Morrow
wrote:
On Mon, Apr 14, 2014 at 4:34 PM, Matthias Leisi
wrote:
They could have communicated, as in "listen folks, we are going to make
a
critical change that wil
On Mon, Apr 14, 2014 at 5:24 PM, Miles Fidelman
wrote:
> Matthias Leisi wrote:
>>
>> On Mon, Apr 14, 2014 at 10:20 PM, Christopher Morrow <
>> morrowc.li...@gmail.com> wrote:
>>
>>> On Mon, Apr 14, 2014 at 4:10 PM, Scott Howard wrote:
Whilst I don't agree with the way that Yahoo has don
On 4/10/14 4:29 AM, Rich Kulawiec wrote:
> An aside:
>
> On Wed, Apr 09, 2014 at 05:15:59PM -0400, William Herrin wrote:
>> Maybe this is a good thing - we can stop getting all the "sorry I'm
>> out of the office" emails when posting to a list.
>
> I entirely support that goal, but my preferred s
Plus I guarantee that something this SIGNIFICANT would catch the attention of
many tech news outlets, social sites, and many email lists if they had given
due notice and allowed people time to digest the change. But, I guess since
everything except their email has become pretty much irrelevant t
On Apr 14, 2014, at 3:58 PM, Rich Kulawiec wrote:
> As I've said many times, email forgery is not the problem. It's a symptom
> of the problem, and the problem is "rotten underlying security" coupled
> with "negligent and incompetent operational practice". But fixing that
> is hard, and nobody
Jim Popovitch wrote:
On Mon, Apr 14, 2014 at 5:24 PM, Miles Fidelman
wrote:
Matthias Leisi wrote:
On Mon, Apr 14, 2014 at 10:20 PM, Christopher Morrow <
morrowc.li...@gmail.com> wrote:
On Mon, Apr 14, 2014 at 4:10 PM, Scott Howard wrote:
Whilst I don't agree with the way that Yahoo has don
On Mon, Apr 14, 2014 at 2:29 PM, Jim Popovitch wrote:
> >> They could have made the change not late on a Friday afternoon (or well
> >> into the weekend for most of the world).
> >>
> >>
> > On the weekend before tax filings are due in the US! And a couple of
> days
> > before Passover.
>
> and
Leo Bicknell wrote:
Ultimately the way to reduce spam is to catch spammers, prosecute them,
and put them in prison. The way we keep all of those other crimes low
is primarily by enforcement; making the punishment not worth the crime.
With spam, the chance that a spammer will be punished is infi
On Mon, Apr 14, 2014 at 5:48 PM, Scott Howard wrote:
> On Mon, Apr 14, 2014 at 2:29 PM, Jim Popovitch wrote:
>>
>> >> They could have made the change not late on a Friday afternoon (or well
>> >> into the weekend for most of the world).
>> >>
>> >>
>> > On the weekend before tax filings are due i
IIRC, the message was sent via courier instead of cable or telephone to prevent
interception. Did the military not even trust its own cryptographic methods? Or
did they not think withdrawal of the Japanese ambassador was not very critical?
matthew black
california state university, long beach
F
On Mon, Apr 14, 2014 at 2:59 PM, Jim Popovitch wrote:
> 7-April: Monday, Yahoo's dmarc change kicks everyone in the groin, the
> last full week before the US tax filing deadline.
>
The change was made on the previous Friday, so that date is largely
irrelevant.
7-April: OpenSSL's *public* adviso
ices were vulnerable at the time of
> public disclosure, I think that's a very large assumption to make...
>
Based on the article below it would appear that Yahoo did NOT know about
Heartbleed at the time of public disclosure.
http://www.smh.com.au/it-pro/security-it/heartbleed-discl
In article
you write:
>On Mon, Apr 14, 2014 at 4:10 PM, Scott Howard wrote:
>> Whilst I don't agree with the way that Yahoo has done this (particularly
>> around communication),
>
>how could they have communicated this better? how can we all learn from this?
Well, telling people in advance that
Jim Popovitch wrote:
On Mon, Apr 14, 2014 at 5:48 PM, Scott Howard wrote:
On Mon, Apr 14, 2014 at 2:29 PM, Jim Popovitch wrote:
They could have made the change not late on a Friday afternoon (or well
into the weekend for most of the world).
On the weekend before tax filings are due in the
On Mon, Apr 14, 2014 at 6:21 PM, Scott Howard wrote:
> On Mon, Apr 14, 2014 at 2:59 PM, Jim Popovitch wrote:
>>
>> 7-April: Monday, Yahoo's dmarc change kicks everyone in the groin, the
>> last full week before the US tax filing deadline.
>
>
> The change was made on the previous Friday, so that
On 4/14/2014 9:38 AM, Matthew Black wrote:
Shouldn't a decent OS scrub RAM and disk sectors before allocating
them to processes, unless that process enters processor privileged
mode and sets a call flag? I recall digging through disk sectors on
RSTS/E to look for passwords and other interesting s
>> for those you can blame the vendor. this one is owned by the
>> community. it falls on us to try to lower the probability of a next
>> one by actively auditing source as our civic duty.
> is that kind of like jury duty? if only it were more like literature,
> which we could read for enjoyment
On 4/14/2014 2:59 PM, Patrick W. Gilmore wrote:
Or we can flame anyone who tries, then wonder why no one is trying.
Amen.
I was just thinking, after reading the umpteenth message here about
spam, about the times in the 1990's that I was literally driven away
because I was trying to get ahe
On 4/14/2014 3:05 PM, William Herrin wrote:
I thought vendors existed primarily as a place to hang the blame when
dealing with a manager or customer who just doesn't get it.
Truth value very high. Humor value, less than none.
--
Requiescas in pace o email Two identifying characte
On 4/14/14 4:06 PM, Randy Bush wrote:
for those you can blame the vendor. this one is owned by the
community. it falls on us to try to lower the probability of a next
one by actively auditing source as our civic duty.
is that kind of like jury duty? if only it were more like literature,
which
Larry Sheldon writes:
> On 4/14/2014 9:38 AM, Matthew Black wrote:
> >Shouldn't a decent OS scrub RAM and disk sectors before allocating
> >them to processes, unless that process enters processor privileged
> >mode and sets a call flag? I recall digging through disk sectors on
> >RSTS/E to look fo
On 04/14/2014 07:14 PM, Michael Thomas wrote:
It's much, much worse than that. I can still read code plenty fine, but
bugs can be
extremely obscure, and triply so with convoluted security code where
people are
actively going after you to find problems in most inventive ways.
Openssl, etc,
probab
In article <534c68f4@cox.net> you write:
>On 4/14/2014 9:38 AM, Matthew Black wrote:
>> Shouldn't a decent OS scrub RAM and disk sectors before allocating
>> them to processes, unless that process enters processor privileged
>> mode and sets a call flag? I recall digging through disk sectors on
On 4/14/2014 7:50 PM, John Levine wrote:
In article <534c68f4@cox.net> you write:
On 4/14/2014 9:38 AM, Matthew Black wrote:
Shouldn't a decent OS scrub RAM and disk sectors before allocating
them to processes, unless that process enters processor privileged
mode and sets a call flag? I rec
On 04/14/2014 05:02 PM, Nathan Angelacos wrote:
On 04/14/2014 07:14 PM, Michael Thomas wrote:
It's much, much worse than that. I can still read code plenty fine, but
bugs can be
extremely obscure, and triply so with convoluted security code where
people are
actively going after you to find prob
This is getting pretty far afield so I thought I should at least
change the subject.
There was no initial withdrawal of the Japanese ambassador - it was
the Japanese withdrawing from negotiations with the USA over USA
demands -- essentially Japan declaring that it had given up on finding
compromis
On 04/14/2014 05:50 PM, John Levine wrote:
In article <534c68f4@cox.net> you write:
On 4/14/2014 9:38 AM, Matthew Black wrote:
Shouldn't a decent OS scrub RAM and disk sectors before allocating
them to processes, unless that process enters processor privileged
mode and sets a call flag? I r
On Mon, Apr 14, 2014 at 07:47:46PM -0700, Doug Barton wrote:
> >It must be quite a while. Unix systems have routinely cleared the RAM
> >and disk allocated to programs since the earliest days.
>
> When you say "clear the disk allocated to programs" what do you mean
> exactly?
>
"On a cl
On Mon, Apr 14, 2014 at 7:47 PM, Doug Barton wrote:
> On 04/14/2014 05:50 PM, John Levine wrote:
>
>> In article <534c68f4@cox.net> you write:
>>
>>> On 4/14/2014 9:38 AM, Matthew Black wrote:
>>>
Shouldn't a decent OS scrub RAM and disk sectors before allocating
them to processes,
On Mon, Apr 14, 2014 at 6:00 PM, Larry Sheldon wrote:
> Is the heartbleed bug not proof positive that it is not being done today?
>
On the contrary. Heartbleed is "proof" that memory IS cleared before being
assigned to a *process*. The data available via the vulnerability is
limited to data fro
70 matches
Mail list logo
