Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Debian

Cryptographic Software in Debian's Main Archive 96

Posted by michael from the groundbreaking-events dept.
Cine writes: "James Troup and Sam Hartman recently sent a note to all debian mirror maintainers, to inform them about the current situation and future plans. Sometime after March 8th, crypto software like OpenSSH, SSL support, and many other enhancements will be integrated into the debian main archive. This is in accordance to legal advice the Debian project received."
This discussion has been archived. No new comments can be posted.

Cryptographic Software in Debian's Main Archive More

Cryptographic Software in Debian's Main Archive

Comments Filter:

  • Crypto (Score:5, Interesting)

    by Ashcrow ( 469400 ) on Saturday March 02, 2002 @12:37AM (#3096578) Homepage
    Crypto helps aid in privacy, and privacy should be available to everyone no matter who they are or where they live.
    • The good news is that crypto is available everywhere. The bad news is it does not work the way it should.

      As US residents who did not know how to program crypto know, crypto is available in outher countries. A few years ago, the easiest way to get secure shell was to get OpenBSD from Canada, or buy something expensive. Programers with access to crypto knowledge could make what they wanted.

      One of the main goals of public key encryption thechnology was to aid people in countries likely to be on US blacklists. Giving those people the ability to communicate privatly is much worse for oppressive governments than any improvement in that government's software library. Governments can usually afford programers and have what they want where they want it.

      Most countries have proved that crypto is a doubtful tool of subversion. Oppresive countries have made cryptography illegal (yes, I'm refering to past US laws and current UK laws). Those that use it only set themselves up for investigation. Indeed, we can be sure that owning a computer at all in some places will earn you a beating.

      I'm happy to see the US going in the right direction for a change. I have and love Debian. One of the best things about it is secure shell. It's great to be able to use and administer my home machines from work or anywhere else in the world without worrying about someone breaking in. "ssh user@mahine -X" run on my lan makes all of my machies transparently usable at once through a single monitor and keyboard. Having this wonderful tool even easier to get is a great step forward. Hopefully the US will consider this one of the weapons to freely distribute from the "Arsenal of Democracy". Go get it!

  • It's as though they just walked up and handed security to those who don't know how to use it. I haven't used debian, but I understand you can install it if you need it, and you need it if you install it. They just made it a lot tougher to maintain mirrors in some respects, and at the same time made it an easier sell.

    • Re:Hi. Here is Crypto (Score:4, Insightful)

      by Mr_Person ( 162211 ) <.gro.nosreprm. .ta. .nosrep_rm.> on Saturday March 02, 2002 @12:52AM (#3096643) Journal
      It's as though they just walked up and handed security to those who don't know how to use it.
      It's not like having extra security without knowing exactly what it does is a bad thing. The Crypto section doesn't just contain things like PGP, but important server utilities like SSH, SSL and other things. It's my opinion that SSH should be installed by default (in place of telnet) on every server as it is much more secure. The people you're talking about probably didn't understand exactly how telnet worked and they probably won't understand exactly how SSH works, but they'll still get the benefits of the extra security as will anyone who depends on the servers that they run.
      • I was looking at globalization more than just having security. Say I moved to France. I could not take it with me, and the French version would be different than the United States version. Not to say that encryption isn't good, but maybe it should be looked at differently than to just add it in there.

  • Hope it works out (Score:4, Interesting)

    by Mr_Person ( 162211 ) <.gro.nosreprm. .ta. .nosrep_rm.> on Saturday March 02, 2002 @12:43AM (#3096600) Journal
    The Debian team has been working on this for a long time. Hopefully it will make installations and upgrades quicker as the servers can now be on the same continent :-).

    One thing that was interesting is that under section 740.13(e) of the US EAR, the software can be exported as long as the people that are exporting it file for export notification. Apparently one thing that they were worried about was whether or not the individual mirrors had to each file or if Debian could just file for the main archives and all the mirrors. According to their legal advice that should be okay. Let's just hope that they don't have any legal problems with it in the future.

  • glad to see (Score:2, Insightful)

    by Partisan01 ( 547933 )
    I'm really glad to see this finally being included into the main archive. I'm also glad to see that they consulted legal sources before charging into any of this. Hopefully they will keep integrating cryptography into the distro more as time goes on. Keep up the good work guys.

  • This advice is bogus. (Score:1, Interesting)

    by Anonymous Coward
    According to the link, as soon as you sell the software you have to file various things.

    This restricts people from selling debian.

    Which makes life hard for CD distributors, and is in contradiction with the GPL.

    Note: I do not sell debian( or any software ).
      1. The distributors don't necessarily need to export the product.
      2. The distributors are not required to put the crypto components on the CD.
      3. There is no GPL violation in not distributing the software in question :-)

    • Re:This advice is bogus. (Score:3, Insightful)

      by Xtifr ( 1323 )
      This restricts people from selling debian.

      Yes, but it's the US gummit doing the restricting. Nor is this issue specific to Debian: any distro which includes crypto-enabled software (mozilla, galeon, even mutt) is going to have the same issues. If you want to sell a modern, non-crippled Linux distro of any type from the US, you're either going to have to:

      a) sell only to US citizens, or
      b) do the paperwork.

      Which makes life hard for CD distributors

      Apparently, the US gummint doesn't care. If I were a US-based CD vendor, I'd definitely complain to my gummint, but I'm not.

      and is in contradiction with the GPL.

      No, the GPL has nothing to do with it. The GPL addresses copyright issues. Other legal issues, like patents and other gummint regulations, are outside the scope of the GPL.

  • And to think... (Score:2, Interesting)

    by ghack ( 454608 )
    ...most projects are un-aware of the fact that open source is exempt. I suppose projects such as openbsd, based in other countries, still have the advantage though - defining when software is sold for a fee is difficult. is a fee only for media, or for a compilation, etc, still under this open source clause?
    • The advice they received was that reasonable charges can be made for distribution and support (but not for licensing) without affecting the export status of the software.

  • no real effect (Score:2, Insightful)

    by Anonymous Coward
    Unless I am missing something, this won't have any real effect on end users. When I request a package to install it, I request it by name and have no idea what subdirectory it is kept in, apt keeps track of this information for me.

    • Re:no real effect (Score:2, Funny)

      by Xtifr ( 1323 )
      Very nearly true. The main end-user effect will be on the bandwidth-challenged, who will find ssh and SSL-enabled versions of mozilla, galeon, mutt, evolution, and ghod knows what else on their CDs in the future. These people will end up saving a lot of download time (and possibly money if they pay by the minute for being online).

      The flip-side of this is that CD vendors in the US might be slightly more reluctant to jump through the hoops necessary to distribute Debian on CD. However, the same hoops are going to be required for any other distros that include non-crippled SSL-enabled apps and the like, so I don't imagine this is going to be a major problem.

      • The flip-side of this is that CD vendors in the US might be slightly more reluctant to jump through the hoops necessary to distribute Debian on CD.

        Nonsense, it'll make things easier. They don't have to burn non-US CDs, which makes images easier to find, and as long as they don't ship to the export-restricted countries (which is easier to filter via mail than download), then they're fine.

        --Dan

    • Re:no real effect (Score:4, Informative)

      by Ray Dassen ( 3291 ) on Saturday March 02, 2002 @06:21AM (#3097249) Homepage

      Unless I am missing something, this won't have any real effect on end users.

      It will have benefits for end users, though probably not highly visible ones.

      Cryptographic software packaged for Debian is available (and has been for a long time already) through non-us.debian.org [debian.org], but crypto-in-main will make further integration of crypto possible. A number of packages in main will get enhanced functionality once crypto is in main. E.g. CVS can start supporting Kerberos for authentication.

      The functionality enhancements made possible by crypto-in-main are not limited to the direct benefits of crypto, as I can illustrate with the Gnumeric [debian.org] package. The Gnumeric spreadsheet can be built to be able to fetch data from databases using GDA [debian.org], the GNU Data Access library. Currently the Debian package is not built with GDA support. The reason for this is that Debian's GDA packages are on non-US (because their source package requires the PostgreSQL development package; PostgreSQL is on non-US as it is built with SSL support). Once we have crypto-in-main, I can build Gnumeric packages that have GDA support (probably in a separate plugin package).

    • Not quite. Because there is crypto software in main, Debian developers now have the option of integrating crypto into the rest of the operating system.
    • This will have a huge effect in the long run, since crypto isn't just used for encryption. It's also used for authentication, and is critical in token-based authentication (e.g., smartcards). With tokens, you have strong authentication ("something you have" (token) and "something you know" (passphrase), lacking only "something you are" (e.g., fingerprint)).

      This allows you to do some really nice things. You want temporary root access? Sure - put your card in the reader and type in your passphrase. Once you remove the card, root access goes away.

      Or you need access to a database containing confidential information? Put in the your card and you gain access to database... but it will be dropped when you remove your card.

      • This will have a huge effect in the long run, since crypto isn't just used for encryption.

        I think you're missing Mr. Coward's point. Crypto was already available to Debian users. To most, this change will be all-but-transparent, due to the magic of apt-get.

  • Perhaps this is a bit offtopic, but Debconf 2002 was also announced [debian.org] today. Will holding it in Canada make a difference crypto-wise? Probably not, but it should be a rockin' good time for participants anyway.

    It's also been conveniently scheduled to coincide nicely with the Ottawa Linux Symposium [linuxsymposium.org]. Other than that, more info will be forthcoming within the next couple of weeks.

  • IP address based restrictions (Score:5, Interesting)

    by cabbey ( 8697 ) on Saturday March 02, 2002 @01:10AM (#3096681) Homepage
    From the lawyer's response:
    Simply posting cryptographic software on a server that may be accessible from an embargoed country does not constitute ``knowledge'' that the software has been exported there. Therefore, criminal liability would not apply to the act of posting. We recommend that you perform IP checking and deny downloads to known embargoed countries. This due diligence also would provide a defense to a claim of civil liability. If you find out that your software has been downloaded to a prohibited destination, then I recommend that you block future downloads to that specific site unless and until you obtain a license from BXA.

    This is the second time I've seen this "recomendation" come out of a legal organization, in almost exactly the same wording no less. I've got to believe therefore that they are pulling it from some other source, such as an official regulation or other document.

    Does anyone have such a list though? Can anyone provide a copy of it? Is it even technically possible to generate? In real time, or even close? I mean sure, it's technically trivial to implement this blocking, just a few iptables/ipchains commands, or some entries in the firewall's firmware... but I think getting that list to begin with is nearly impossible. How do you know where the other end of the phone line that is dialed into some modem bank on the other side of the net is?

    In the last instance that I saw this (an external server at work) corporate legal was threatening to pull the plug if the admins didn't provide proof they were doing this. After much head scratching and searching the net my sugested response was that they would be happy to implement this just as soon as the legal department provided them with such a list.

    I'm told they never heard back from legal on that topic.
    • Does anyone have such a list though? Can anyone provide a copy of it? Is it even technically possible to generate? In real time, or even close?
      Well, the Debian announcement says this:
      BXA regulations require that you not knowingly export to embargoed countries, as a show of good faith you may wish to consider implementing a reverse IP lookup that identifies the computer requesting the download, and that blocks downloads of the cryptographic archive to countries embargoed by the United States: Cuba (.cu), Iran (.ir), Iraq (.iq), Libya (.ly), North Korea (.kp), Syria (.sy), Sudan (.sd) and Taliban Occupied Afghanistan.
      I know it's not an IP list, but it would be fairly simple to impliment - just block those TLD's. I suppose it would slow your server down some, having to reverse resolve every IP that connects to it. As far as updating the list, that shouldn't be too hard - all you have to do is have your lawyer give you a call every time a country is added or removed from the list (how often does that happen?) and just add their ccTLD to the block list. Or, just did a quick Google search and you can get a list from the U.S. Department of State [pmdtc.org].
      • The list of contries is easy to get sure, but as you said: the reverse lookups (1) will kill your server and (2) will open you up to more DOS attacks . Just imagine a dns server that doesn't properly close connections, forcing them to time out, now imagine two or three of them configured into a delegation round robin... a few incoming requests and your machine grinds itself into dust trying to resolve the reverse IP... get enough of those and you'll tie up enough socket resources to choke the machine. Also a reverse DNS entry isn't a requirement, many networks don't provide them. Working from domain names just doesn't seem technically feasible... pulling netblocks from iana maybe more doable, but still isn't even close to 100% accurate.

        • Re:IP address based restrictions (Score:4, Informative)

          by fferreres ( 525414 ) on Saturday March 02, 2002 @03:21AM (#3096941)
          No reverse lookups needed. There are publicly available IP mappings databases. If the IP has been assigned to a banned country, then it IS in the list.

          I suggest the debian maintainers should check at LEAST this site.

          http://caida.org

          If you want to testdrive the acuracy of the mappings, why not check if it works fine for your connection. Just inset your IP number and go!:

          http://netgeo.caida.org/perl/netgeo.cgi?target=& me thod=getCountry&nonblocking=true";
        • and of course, those of us working and living in these 'embargoed' countries are already using US based proxies to avoid the censorship at home. Those 'restrictions' are no restrictions at all.

      • Re:IP address based restrictions (Score:5, Funny)

        by Waffle Iron ( 339739 ) on Saturday March 02, 2002 @01:54AM (#3096785)
        I sleep better at night knowing that through the tireless diligence of webmasters all over the world, running millions of reverse IP lookups every day, there is probably not a single copy of ssh available in any of those countries. Kudos to all those who participate in this grand, impenetrable virtual fortress.

        This achievement is a real testament to the vision and wisdom of our leaders.

    • If I remember correctly, Netscape used to use this technic but it was the opposite where you could not download the software unless you were from an US IP address but it failed and I could never download Netscape with 128bit encryption even though I was in the US and using an university computer.

  • It amazes me that the U.S. government has done as much as it can to try to outlaw privacy. To me, it seems that things are out of control in some parts of the U.S. government. The U.S. spends more on surveillance of everyone everywhere than any country ever has in the history of the world. Money is spent on being sneaky, rather than on making good relationships.

    It is futile to try to avoid the export of software, particularly when having it is legal in other countries. Yet taxpayer money is spent on this. The U.S. government, in my opinion, should not try to control the entire world.

    More on the extremes of U.S. government policy: What should be the Response to Violence? [hevanet.com]

  • This is just a bad idea. (Score:4, Informative)

    by njdj ( 458173 ) on Saturday March 02, 2002 @04:21AM (#3097083)
    For the Debian end user, getting stuff like OpenSSH has been very easy, contrary to what some posters have said. There is little or no benefit for most end users in this change; and a huge increase in trouble and inconvenience for some end users, who happen to be citizens or residents of a country like Cuba that the Bush regime doesn't currently like.

    US crypto regulations are not only a nuisance, they're also volatile. "Things are getting better", we hear. Bullshit. Things are changing unpredictably. Few people (and certainly no software developers) have any idea what US policy will be next year.

    The only sensible policy is to keep the crypto archive in a country that has never had export regulations for crypto software (there are many).
    • I don't think this is a bad idea.

      As you say, it is very easy to get non-US software, add a line in sources.list, and never think about it again. However, there are a lot of other applications where crypto isn't needed for the package to work.

      For example, you can get 'lynx' from the main server. If you need https support, just fetch the 'lynx-ssl' package from the non-US server.

      But what if the maintainer is from the USA? I suppose that would prohibit him from uploading such a package to the non-US server.

      Compare the LDAP utilities. There is no cryptographic version of them in the Debian archive. Ben Collins couldn't upload them.

      Of course, I do some magic with stunnel to get my passwords encrypted anyway, but it's not the best way to go.

      And the LDAP packages are just an example. How many other packages out there would be built with the (optional) crypto support, if they could be uploaded in the US main archive?
  • Yay! Now I should be able to get this stuff from the nearby and really fast mirror on campus. Ahh..

    Now, I just wonder if the FreeS/WAN folks will ever get their code integrated with the standard Linux kernel..

Slashdot Top Deals

Any sufficiently advanced technology is indistinguishable from magic. -- Arthur C. Clarke

Close