Re: [PATCH] Add dist-f12 to the static repos.
On Mon, 30 Mar 2009, Ricky Zhou wrote:
> On 2009-03-30 08:44:29 PM, Jesse Keating wrote:
> > We're allowing for early branching now.
> > ---
> > configs/build/update-static-repos.py |2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/configs/build/update-static-repos.py
> > b/configs/build/update-static-repos.py
> > index 16ee6ac..98d48c9 100755
> > --- a/configs/build/update-static-repos.py
> > +++ b/configs/build/update-static-repos.py
> > @@ -4,7 +4,7 @@ import os
> > import sys
> > import koji
> >
> > -TAGS = ('dist-olpc2-build', 'dist-olpc3-build', 'dist-olpc4-build',
> > 'dist-f8-build', 'dist-f9-build', 'dist-f10-build', 'dist-f11-build',
> > 'dist-rawhide', 'olpc2-update1', 'olpc2-ship2')
> > +TAGS = ('dist-olpc2-build', 'dist-olpc3-build', 'dist-olpc4-build',
> > 'dist-f9-build', 'dist-f10-build', 'dist-f11-build', 'dist-f12-build',
> > 'dist-rawhide', 'olpc2-update1', 'olpc2-ship2')
> > STATICPATH = '/mnt/koji/static-repos'
> > SUFFIX = '-current'
> >
> > --
> +1
>
+1
-Mike
___
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: More auth options
On Mon, 30 Mar 2009, Todd Zullinger wrote: > Dennis Gilmore wrote: > > ubikey is max USD$25 where the etoken is probably at least USD$30. > > I would think that with yubikey we could work out a deal with them > > to get a discount in return for us being a case study/prominent user > > of there product. all of the software for yubikey AFAICT is open > > source. some of it would require packaging. > > A friend of mine bought a Yubikey recently and I helped him package up > libyubikey-client and pam_yubico. In case anyone wants to look into > this and doesn't want to have to start completely from stratch, these > spec files might help: http://tmz.fedorapeople.org/specs/ > Interesting, if you wouldn't mind having him join the list or blog about his experiences, I'd be interested in reading it. -Mike ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: sysadmin group
On Mon, 30 Mar 2009, Rino Mardo wrote: > ok i found a FIG and it's called sysadmin. i think this is the closest > to my actual experience. > > i want to join sysadmin. should i apply now or wait for a nod? > Yep, that's a good one to apply for as any other sysadmin-* groups require it. Let me know once you've applied and I'll make sure to sponsor you... beware though... you'll start getting nagios alerts. -Mike ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: An Introduction
On Mon, 30 Mar 2009, Rino Mardo wrote: > Hello, my name is Ferino Mardo but you can call me Rino. I am a > network professional having been in the industry for more than 18 > years. I used to be a coder (from assembler to C) but now working as a > network manager. I don't consider myself a newbie though I also don't > call myself a h4ck3r :-) but I do know my way around computers and the > Internet. > > I have time available and want to contribute it to this dynamic team. > i used to do shell scripts but that part is now rusted because my > company now is using closed source softwares. As the nature of things > outside of the US, we techies don't have any specialization to speak > of. If you know a little sql command, bang!, you're the dba. but i do > know my dns (also rusty), firewalls (closed source too), WAN > management, UTP network cabling (handmade), install and maintain > server OS, do patches, and other things as needed to do the job. > > Lookin at the FIG, I'm not sure which to join I hope someone can > suggest a starting point? > > Am looking forward to contribute and hope to "see" you soon! > > > Regards, > > Rino Mardo > Welcome Rino, a good place to start is to stop by #fedora-admin on irc.freenode.net and say hey. If you cannot thats totally ok too and you can participate on the list. -Mike ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: [PATCH] Add dist-f12 to the static repos.
On 2009-03-30 08:44:29 PM, Jesse Keating wrote:
> We're allowing for early branching now.
> ---
> configs/build/update-static-repos.py |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/configs/build/update-static-repos.py
> b/configs/build/update-static-repos.py
> index 16ee6ac..98d48c9 100755
> --- a/configs/build/update-static-repos.py
> +++ b/configs/build/update-static-repos.py
> @@ -4,7 +4,7 @@ import os
> import sys
> import koji
>
> -TAGS = ('dist-olpc2-build', 'dist-olpc3-build', 'dist-olpc4-build',
> 'dist-f8-build', 'dist-f9-build', 'dist-f10-build', 'dist-f11-build',
> 'dist-rawhide', 'olpc2-update1', 'olpc2-ship2')
> +TAGS = ('dist-olpc2-build', 'dist-olpc3-build', 'dist-olpc4-build',
> 'dist-f9-build', 'dist-f10-build', 'dist-f11-build', 'dist-f12-build',
> 'dist-rawhide', 'olpc2-update1', 'olpc2-ship2')
> STATICPATH = '/mnt/koji/static-repos'
> SUFFIX = '-current'
>
> --
+1
Thanks,
Ricky
pgpujOls9fbFA.pgp
Description: PGP signature
___
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
[PATCH] Add dist-f12 to the static repos.
We're allowing for early branching now.
---
configs/build/update-static-repos.py |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/configs/build/update-static-repos.py
b/configs/build/update-static-repos.py
index 16ee6ac..98d48c9 100755
--- a/configs/build/update-static-repos.py
+++ b/configs/build/update-static-repos.py
@@ -4,7 +4,7 @@ import os
import sys
import koji
-TAGS = ('dist-olpc2-build', 'dist-olpc3-build', 'dist-olpc4-build',
'dist-f8-build', 'dist-f9-build', 'dist-f10-build', 'dist-f11-build',
'dist-rawhide', 'olpc2-update1', 'olpc2-ship2')
+TAGS = ('dist-olpc2-build', 'dist-olpc3-build', 'dist-olpc4-build',
'dist-f9-build', 'dist-f10-build', 'dist-f11-build', 'dist-f12-build',
'dist-rawhide', 'olpc2-update1', 'olpc2-ship2')
STATICPATH = '/mnt/koji/static-repos'
SUFFIX = '-current'
--
1.5.5.6
___
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: More auth options
Dennis Gilmore wrote: > ubikey is max USD$25 where the etoken is probably at least USD$30. > I would think that with yubikey we could work out a deal with them > to get a discount in return for us being a case study/prominent user > of there product. all of the software for yubikey AFAICT is open > source. some of it would require packaging. A friend of mine bought a Yubikey recently and I helped him package up libyubikey-client and pam_yubico. In case anyone wants to look into this and doesn't want to have to start completely from stratch, these spec files might help: http://tmz.fedorapeople.org/specs/ -- ToddOpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~ I am free of all prejudice. I hate everyone equally. -- W. C. Fields pgp71ho5VF9eo.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
sysadmin group
ok i found a FIG and it's called sysadmin. i think this is the closest to my actual experience. i want to join sysadmin. should i apply now or wait for a nod? ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
An Introduction
Hello, my name is Ferino Mardo but you can call me Rino. I am a network professional having been in the industry for more than 18 years. I used to be a coder (from assembler to C) but now working as a network manager. I don't consider myself a newbie though I also don't call myself a h4ck3r :-) but I do know my way around computers and the Internet. I have time available and want to contribute it to this dynamic team. i used to do shell scripts but that part is now rusted because my company now is using closed source softwares. As the nature of things outside of the US, we techies don't have any specialization to speak of. If you know a little sql command, bang!, you're the dba. but i do know my dns (also rusty), firewalls (closed source too), WAN management, UTP network cabling (handmade), install and maintain server OS, do patches, and other things as needed to do the job. Lookin at the FIG, I'm not sure which to join I hope someone can suggest a starting point? Am looking forward to contribute and hope to "see" you soon! Regards, Rino Mardo Key fingerprint = 71E1 31C1 7CE8 9E5A 295E 36B9 8BE8 C3B5 414B FCBD ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: More auth options
On Mon, Mar 30, 2009 at 11:57 AM, Dennis Gilmore wrote: > So doing a liitle looking around I cane across some options that look > interesting, the following options would mean you need to physically have > something to login. > > yubikey > http://www.yubico.com/products/yubikey/ > It would require a pam module and for us to setup a server for managing keys. > it looks to be fairly low cost. it would implement a 2 facter > authentication. > > etoken > http://www.aladdin.com/etoken/devices/pro-usb.aspx > These do look interesting and maybe better than the S/Key 64 bit key. I remember some bad stories about one of the 'Aladdin' companies (there are quite a few who use that name for security products).. but not sure which. The bigger question is who can we get some 'professional' opinions from? My crypto math is not good so I could not give an opinion of whether one usage of AES-128 versus another usage was equivalent, better, or worse. I would hate for us to end up with any solution that would end up on Shneier's Snake Oil pages. [I remember one token device that some people I know evaluated a while back that while it stored the key encrypted in AES-128 etc.. it had a register where it stored the unencrypted user token and could be looked at under any OS other than Windows.] -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: More auth options
> Date: Mon, 30 Mar 2009 12:57:23 -0500 > From: Dennis Gilmore > Reply-To: Fedora Infrastructure > To: Fedora Infrastructure > Subject: More auth options > > So doing a liitle looking around I cane across some options that look > interesting, the following options would mean you need to physically have > something to login. > > yubikey > http://www.yubico.com/products/yubikey/ > It would require a pam module and for us to setup a server for managing keys. > it looks to be fairly low cost. it would implement a 2 facter > authentication. > > etoken > http://www.aladdin.com/etoken/devices/pro-usb.aspx > > it moves the public key from your hard drive to something you physically need > to have > > > ubikey is max USD$25 where the etoken is probably at least USD$30. I would > think that with yubikey we could work out a deal with them to get a discount > in return for us being a case study/prominent user of there product. all of > the software for yubikey AFAICT is open source. some of it would require > packaging. Dennis, I know RSA is a bit expensive, but it might be worth thinking about RSA tokens as well. They have a OTP that changes every 60 seconds plus you have to add a PIN as well. Matt -- Matthew Galgoci Network Operations Red Hat, Inc 919.754.3700 x44155 ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: More auth options
On Mon, Mar 30, 2009 at 2:12 PM, Matthew Galgoci wrote: >> Date: Mon, 30 Mar 2009 12:57:23 -0500 >> From: Dennis Gilmore >> Reply-To: Fedora Infrastructure >> To: Fedora Infrastructure >> Subject: More auth options >> >> So doing a liitle looking around I cane across some options that look >> interesting, the following options would mean you need to physically have >> something to login. >> >> yubikey >> http://www.yubico.com/products/yubikey/ >> It would require a pam module and for us to setup a server for managing keys. >> it looks to be fairly low cost. it would implement a 2 facter >> authentication. >> >> etoken >> http://www.aladdin.com/etoken/devices/pro-usb.aspx >> >> it moves the public key from your hard drive to something you physically need >> to have >> >> >> ubikey is max USD$25 where the etoken is probably at least USD$30. I would >> think that with yubikey we could work out a deal with them to get a discount >> in return for us being a case study/prominent user of there product. all of >> the software for yubikey AFAICT is open source. some of it would require >> packaging. > > Just FYI, Aladdin refused, REFUSED to sell me 4 keys when I attempted > to purchase them through CDW because I did have or want to have an > Aladdin PKI Console software license. Nevermind that I didn't actually > need their Console software or that Red Hat has a PKI management > product. > > In my opinion, avoid Aladdin even if you can manage to get keys through > a tertiary party. +1 - Aladdin makes a lot of DRM (for software, not media (that I know of)) stuff too; all the more reason to avoid them. If Ubikey is supplying an open source stack to go with their hardware that sounds a more logical fit for the Fedora Project, and a more symbiotic relationship. ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: More auth options
> Date: Mon, 30 Mar 2009 12:57:23 -0500 > From: Dennis Gilmore > Reply-To: Fedora Infrastructure > To: Fedora Infrastructure > Subject: More auth options > > So doing a liitle looking around I cane across some options that look > interesting, the following options would mean you need to physically have > something to login. > > yubikey > http://www.yubico.com/products/yubikey/ > It would require a pam module and for us to setup a server for managing keys. > it looks to be fairly low cost. it would implement a 2 facter > authentication. > > etoken > http://www.aladdin.com/etoken/devices/pro-usb.aspx > > it moves the public key from your hard drive to something you physically need > to have > > > ubikey is max USD$25 where the etoken is probably at least USD$30. I would > think that with yubikey we could work out a deal with them to get a discount > in return for us being a case study/prominent user of there product. all of > the software for yubikey AFAICT is open source. some of it would require > packaging. Just FYI, Aladdin refused, REFUSED to sell me 4 keys when I attempted to purchase them through CDW because I did have or want to have an Aladdin PKI Console software license. Nevermind that I didn't actually need their Console software or that Red Hat has a PKI management product. In my opinion, avoid Aladdin even if you can manage to get keys through a tertiary party. -- Matthew Galgoci Network Operations Red Hat, Inc 919.754.3700 x44155 ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
More auth options
So doing a liitle looking around I cane across some options that look interesting, the following options would mean you need to physically have something to login. yubikey http://www.yubico.com/products/yubikey/ It would require a pam module and for us to setup a server for managing keys. it looks to be fairly low cost. it would implement a 2 facter authentication. etoken http://www.aladdin.com/etoken/devices/pro-usb.aspx it moves the public key from your hard drive to something you physically need to have ubikey is max USD$25 where the etoken is probably at least USD$30. I would think that with yubikey we could work out a deal with them to get a discount in return for us being a case study/prominent user of there product. all of the software for yubikey AFAICT is open source. some of it would require packaging. Dennis ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Intrusion Update
On Mon, 30 Mar 2009, susmit shannigrahi wrote: > >> Supposedly, they will not have access to the mobile device/pager where > >> this single time password will be sent. > >> > > > > Interestingly I saw someone doing something very similar to this at pycon > > using asterisk. > > > You mean, pretend to be another number using asterix > and grab this single time passwd? > > I mean calling people when they try to log in. -Mike ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Intrusion Update
Damian Myerscough wrote: > I have just done some research on SSH and S/Key and I read that S/Key > cannot withstand a brute forced attack [1] > > [1] http://www.gentoo-wiki.info/OpenSSH_skey OTPW looks better: http://en.wikipedia.org/wiki/OTPW ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Intrusion Update
On Mon, Mar 30, 2009 at 9:46 AM, Mike McGrath wrote: > On Mon, 30 Mar 2009, Damian Myerscough wrote: > >> Hello, >> >> What about the use of S/Key (one-time passwords) I think it is possible to >> deploy SSH with S/Key authentication. I haven't look into it that much but it >> could be a possible solution? >> > > If someone had my username, password, and ssh key. How would that prevent > them from getting a otp? > > -Mike > Well normally they would have only your 1st password... and you would need a new OTP to become root etc. The big problem with S/KEY is the short search space (8 ASCII characters basically which can still take Petabytes for a dictionary attack). A place I used to work at had a similar problem a couple of years ago. Lessons learned was that OTP passwords were one of the most effective limiters. The second limiter was time limits on kerberos keys which limited how long having an OTP was useful to the attacker. Where people had gotten around this, we ran into issues: 1) Kerberos tickets with long lifes. 2) Forwarding tickets with high trust between all systems. 3) Proxiable tickets working between clusters 4) sudo without password Where people run into problems are: 1) Writing down the OTP passwords in their computer 2) Running the OTP calculator on their computer versus seperate device. 3) OTP passwords with 2 short of a length (8 minimum) Also in the end some processes MUST have human interaction. Depending on the level of trust you wish to impart on something, packages may only be signed on certain machines, from certain terminals, booted from cold boot via secure media, etc etc. -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Intrusion Update
>> Supposedly, they will not have access to the mobile device/pager where >> this single time password will be sent. >> > > Interestingly I saw someone doing something very similar to this at pycon > using asterisk. You mean, pretend to be another number using asterix and grab this single time passwd? -- Regards, Susmit. = ssh 0x86DD170A http://www.fedoraproject.org/wiki/user:susmit = Sent from: Calcutta WB India. ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Intrusion Update
On Mon, Mar 30, 2009 at 9:22 PM, Damian Myerscough wrote: > I have just done some research on SSH and S/Key and I read that S/Key cannot > withstand a brute forced attack [1] > > [1] http://www.gentoo-wiki.info/OpenSSH_skey True, but We can lock out an account after 10 (or 100) invalid attempts. Brute-force will require more than that number of attempts. A six latter password will require few hundred (~380) million generations. -- Regards, Susmit. = ssh 0x86DD170A http://www.fedoraproject.org/wiki/user:susmit = Sent from: Calcutta WB India. ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Intrusion Update
On Mon, 30 Mar 2009, susmit shannigrahi wrote: > > If someone had my username, password, and ssh key. How would that prevent > > them from getting a otp? > > > Supposedly, they will not have access to the mobile device/pager where > this single time password will be sent. > Interestingly I saw someone doing something very similar to this at pycon using asterisk. -Mike___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Intrusion Update
Mike McGrath wrote: > On Mon, 30 Mar 2009, Damian Myerscough wrote: >> What about the use of S/Key (one-time passwords) I think it is possible to >> deploy SSH with S/Key authentication. I haven't look into it that much but it >> could be a possible solution? > > If someone had my username, password, and ssh key. How would that prevent > them from getting a otp? To do that, they'd need to know your otp passphrase. ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Intrusion Update
> Date: Mon, 30 Mar 2009 16:52:24 +0100 > From: Damian Myerscough > To: Mike McGrath > Cc: Fedora Infrastructure > Subject: Re: Intrusion Update > > I have just done some research on SSH and S/Key and I read that S/Key cannot > withstand a brute forced attack [1] > > [1] http://www.gentoo-wiki.info/OpenSSH_skey In addition, skey-like authentication schemes only work if the end users of aren't automating their login process and keep the skey-like program on a separate system like a pda. Believe me, if you implement an skey-alike you will have users dumb enough to automate their login processes and run the skey-like calculator on the same machine they are logging in from. -- Matthew Galgoci Network Operations Red Hat, Inc 919.754.3700 x44155 ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Intrusion Update
> If someone had my username, password, and ssh key. How would that prevent > them from getting a otp? Supposedly, they will not have access to the mobile device/pager where this single time password will be sent. -- Regards, Susmit. = ssh 0x86DD170A http://www.fedoraproject.org/wiki/user:susmit = Sent from: Calcutta WB India. ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Intrusion Update
I have just done some research on SSH and S/Key and I read that S/Key cannot withstand a brute forced attack [1] [1] http://www.gentoo-wiki.info/OpenSSH_skey Mike McGrath wrote: On Mon, 30 Mar 2009, Damian Myerscough wrote: Hello, What about the use of S/Key (one-time passwords) I think it is possible to deploy SSH with S/Key authentication. I haven't look into it that much but it could be a possible solution? If someone had my username, password, and ssh key. How would that prevent them from getting a otp? -Mike susmit shannigrahi wrote: So I'm not quite sure how to 'fix' this problem. By that I mean, even if we knew this attack was going to happen I'm not totally sure of a feasible solution, using only free software, that we could have used to fix it. Obviously a physical rsa key or the like would have worked but I don't think we have the manpower nor budget to implement such a system. So I ask the list, any ideas? A single use random code/passwd mailed/texted each time one tries to login and invalidated just after use?? Basically I am referring to RFC 2289[1] [1]http://www.ietf.org/rfc/rfc2289.txt Thanks. -- Regards, Damian Myerscough ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list -- Regards, Damian Myerscough ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Intrusion Update
On Mon, 30 Mar 2009, Damian Myerscough wrote: > Hello, > > What about the use of S/Key (one-time passwords) I think it is possible to > deploy SSH with S/Key authentication. I haven't look into it that much but it > could be a possible solution? > If someone had my username, password, and ssh key. How would that prevent them from getting a otp? -Mike > susmit shannigrahi wrote: > > > So I'm not quite sure how to 'fix' this problem. By that I mean, even if > > > we knew this attack was going to happen I'm not totally sure of a feasible > > > solution, using only free software, that we could have used to fix it. > > > Obviously a physical rsa key or the like would have worked but I don't > > > think we have the manpower nor budget to implement such a system. So I > > > ask the list, any ideas? > > > > A single use random code/passwd mailed/texted each time one tries to > > login and invalidated just after use?? > > > > Basically I am referring to RFC 2289[1] > > > > [1]http://www.ietf.org/rfc/rfc2289.txt > > > > Thanks. > > > > -- > Regards, > Damian Myerscough > > ___ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: [Change Request] Transifex 0.5.1-2
Xavier Lamien wrote: > 2009/3/30 Mike McGrath : >> On Mon, 30 Mar 2009, Diego Búrigo Zacarão wrote: >> >>> I'm sorry guys, but we had a minor problem with the tar.gz on the previous >>> RPM. >>> Can I have +1's for a new update on app1 to the 0.5.1-2 building? >>> >>> http://buildsys.fedoraproject.org/plague-results/fedora-5-epel/transifex/0.5.1-2.el5/noarch/ >>> >> +1 > > +1 > +1 -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Intrusion Update
Opps Sorry I didn't check the link Susmit posted. susmit shannigrahi wrote: So I'm not quite sure how to 'fix' this problem. By that I mean, even if we knew this attack was going to happen I'm not totally sure of a feasible solution, using only free software, that we could have used to fix it. Obviously a physical rsa key or the like would have worked but I don't think we have the manpower nor budget to implement such a system. So I ask the list, any ideas? A single use random code/passwd mailed/texted each time one tries to login and invalidated just after use?? Basically I am referring to RFC 2289[1] [1]http://www.ietf.org/rfc/rfc2289.txt Thanks. -- Regards, Damian Myerscough ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Intrusion Update
Hello, What about the use of S/Key (one-time passwords) I think it is possible to deploy SSH with S/Key authentication. I haven't look into it that much but it could be a possible solution? susmit shannigrahi wrote: So I'm not quite sure how to 'fix' this problem. By that I mean, even if we knew this attack was going to happen I'm not totally sure of a feasible solution, using only free software, that we could have used to fix it. Obviously a physical rsa key or the like would have worked but I don't think we have the manpower nor budget to implement such a system. So I ask the list, any ideas? A single use random code/passwd mailed/texted each time one tries to login and invalidated just after use?? Basically I am referring to RFC 2289[1] [1]http://www.ietf.org/rfc/rfc2289.txt Thanks. -- Regards, Damian Myerscough ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Intrusion Update
> So I'm not quite sure how to 'fix' this problem. By that I mean, even if > we knew this attack was going to happen I'm not totally sure of a feasible > solution, using only free software, that we could have used to fix it. > Obviously a physical rsa key or the like would have worked but I don't > think we have the manpower nor budget to implement such a system. So I > ask the list, any ideas? A single use random code/passwd mailed/texted each time one tries to login and invalidated just after use?? Basically I am referring to RFC 2289[1] [1]http://www.ietf.org/rfc/rfc2289.txt Thanks. -- Regards, Susmit. = ssh 0x86DD170A http://www.fedoraproject.org/wiki/user:susmit = Sent from: Calcutta WB India. ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Intrusion Update
On Mon, 30 Mar 2009, Mike McGrath wrote: > For those not on the announce list: > > https://www.redhat.com/archives/fedora-announce-list/2009-March/msg00010.html > Oh! I forgot something too, I've been waiting for this to go out so we could discuss authentication mechanisms. Passwords + ssh keys just aren't the most secure method of authentication. Our policy on private keys is pretty clear now but there's always room for improvement. So I'm not quite sure how to 'fix' this problem. By that I mean, even if we knew this attack was going to happen I'm not totally sure of a feasible solution, using only free software, that we could have used to fix it. Obviously a physical rsa key or the like would have worked but I don't think we have the manpower nor budget to implement such a system. So I ask the list, any ideas? -Mike ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Intrusion Update
For those not on the announce list: https://www.redhat.com/archives/fedora-announce-list/2009-March/msg00010.html -Mike ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: [Change Request] Transifex 0.5.1-2
2009/3/30 Mike McGrath : > On Mon, 30 Mar 2009, Diego Búrigo Zacarão wrote: > >> I'm sorry guys, but we had a minor problem with the tar.gz on the previous >> RPM. >> Can I have +1's for a new update on app1 to the 0.5.1-2 building? >> >> http://buildsys.fedoraproject.org/plague-results/fedora-5-epel/transifex/0.5.1-2.el5/noarch/ >> > > +1 +1 -- Xavier.t Lamien -- http://fedoraproject.org/wiki/XavierLamien GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: [Change Request] Transifex 0.5.1-2
On Mon, 30 Mar 2009, Diego Búrigo Zacarão wrote: > I'm sorry guys, but we had a minor problem with the tar.gz on the previous > RPM. > Can I have +1's for a new update on app1 to the 0.5.1-2 building? > > http://buildsys.fedoraproject.org/plague-results/fedora-5-epel/transifex/0.5.1-2.el5/noarch/ > +1 -Mike___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
[Change Request] Transifex 0.5.1-2
I'm sorry guys, but we had a minor problem with the tar.gz on the previous RPM. Can I have +1's for a new update on app1 to the 0.5.1-2 building? http://buildsys.fedoraproject.org/plague-results/fedora-5-epel/transifex/0.5.1-2.el5/noarch/ Thanks -- Diego Búrigo Zacarão http://diegobz.net Linux User #402589 USE SOFTWARE LIVRE ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
