ey
up_the_irons: please don't forget my ne2k_pci ticket, I'd be glad to have it done when I wake up in a few hours :-)
hello
hiya
nesta: mind if i priv msg you?
sure
go ahead
up_the_irons: hit me up when you are around please.
32 packets transmitted, 5 packets received, 84.4% packet loss
round-trip min/avg/max/stddev = 97.851/104.179/112.136/6.145 ms
any problem now?
112 packets transmitted, 23 received, 79% packet loss, time 110990ms
to my host..
(from 2 places UK/Japan.. so, looks not my side problem..)
=(
nakano: i started getting alerts from pingdom 44 mins ago
i just reported the same issue. but looks nobody here..
sounds yours and mine are on the same place..
http://world.ckan.net/
... oops... wrong channel
looks better now.. but still something wrong..
ohh joy. another discussion about how *BSD ports are insecure because they don't use signing keys.
lol
cedwards: ?
nesta: in one of the LUG channels I lurk in someone brought up this article [http://bsdly.blogspot.com/2010/10/if-it-runs-openbsd-it-has-to-be.html] as proof GPG signing is the one true way (tm)
ahhhh
hehe
thanks
cedwards: do you think gpg signing would hurt though?
I don't think it adds much, particularly in a ports-based environment.
especially when an md5 checksum is verified unless deliberately disabled.
I had the privilege of being flamed by Mr Deraadt once, because I asked why some sha256 check was failing
he told me to lower my expectations
tinono: that's good advice for life
"a checksum can fail. it's ok."
2 people in the community I have little respect for:  TDR and RMS.
I think the probability of someone gaining access to a GPG signing key is much higher than it is of altering both my local ports-tree and the upstream .tar.gz.
both fairly intelligent,  but both also seem to be of the mindset that we're not intelligent enough to make decisions for ourselves.
I don't think the probability of such an attack is very high. still, it only takes one compromised makefile on the master cvs.
no need to alter any disfile
I think more likely,  is the source code itself being maliciously edited,  that a port tarball.   as we've seen in the past.
yes
and once again, in most of those cases, the lack of signing was at fault.
tinono: using a gpg sig for a port tarball doesn't help, if the projects source code itself is compromised.  (think unrealircd a few months back)
of course it doesn't
then you're arguing apples and oranges.
unrealircd took action, and now they sign releases.
I'm reminded of when the Red Hat / Fedora build server was compromised and they had to generate a new key.
every step where tampering can be dangerous, signing can help
tinono: unreal got drastically owned
they kinda had to to save face
but yeh..
indeed
tis good anyway
in any case. I've argued this with this user a dozen times. He's Debian to the bone, and I prefer the ports system.
so do i. i still think it could welcome some for of signing as an improvement :-p
I don't know that you get better than having an independent local copy of the md5/sha to verify the upstream .tar.gz
that's the point of signing. you trust that the information contained in the port comes from where it's supposed to come. This information includes the sha/md5 for the distfile, but also the url for the distfile.
not to mention all the bad things a Makefile 'running' as root can do :-)
but ey, I'm not really losing sleep over it. just saying I guess it wouldn't hurt.
I remain unconvinced that the extra effort would actually be beneficial.
It might very well not be warranted. Talk is cheap. Those who have to support all that make the decisions, I'm fine with that :)
hrm
anything I should know about updating to 4.7?
just run -current  =)
and follow src-changes. then upgrading is never really an issue