Linux

As you may be aware, starting with 4.12-rc1 Linus will no longer provide signed tarballs and patches for pre-release ("-rc") kernels. Reasons for this are multiple, but largely this is because people who are most interested in pre-release tags -- kernel developers -- do not rely on patches and tarballs to do their work. Obtaining tarballs on your own Here is how you can generate the tarball from a pre-release tag using the "git archive" command (we'll use 4.12-rc1 in these examples): git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git cd linux git verify-tag v4.12-rc1 git archive --format=tar.gz --prefix=linux-4.12-rc1/ \ -o linux-4.12-rc1.tar.gz v4.12-rc1 The upside of this method is that during the "git verify-tag" step you will check the PGP signature on the tag to make sure that what you cloned is exactly the same tree as on Linus Torvalds's computer. The downside of this method is that you will need to download about 1 GiB of data -- the entire git history of the Linux kernel -- just to get the latest tag. Notably, when -rc2 is tagged, all you'll need to do is run a quick "git pull" to get the latest objects and it will be dramatically less data to download, so cloning the whole tree may be worth it to you in the long run if you plan to do this again in the future. If you do not want to download the whole git repository and just want to get the latest tarball, you can download the version automatically generated by cgit at the following (or similar URL): wget https://git.kernel.org/torvalds/t/linux-4.12-rc1.tar.gz Please note that you will not be able to cryptographically verify the integrity of this archive, but the download will be about 10 times less in size than the full git tree. Obtaining patches to the previous mainline If you would like to get just the patch to the previous mainline release, you can get it from cgit as well: wget -O patch-4.12-rc1 https://git.kernel.org/torvalds/p/v4.12-rc1/v4.11 Unfortunately, cgit does not currently offer an easy way to get gzip-compressed patches, but if you would like to reduce the amount of data you download, you can use http-level gzip compression: wget -O patch-4.12-rc1.gz --header="accept-encoding: gzip" \ https://git.kernel.org/torvalds/p/v4.12-rc1/v4.11 The links to these patches are available on the front page of https://www.kernel.org/. Why not provide these at their old locations? We intentionally did not provide these automatically generated tarballs and patches in locations previously used by Linus (/pub/linux/kernel/v4.x/testing), even if this meant potentially breaking automated scripts relying on contents published there. Anything placed in the /pub tree is signed and curated directly by developers and all patches and software archives published there invariably come with a PGP signature provided directly by the developer of that software (or one of the developers). Patches and tarballs automatically generated by git.kernel.org are NOT a replacement for this stringent process, but merely a convenience service that comes with very different trust implications. By providing these at different URLs we wanted all users of these services to make a conscious decision on whether they want to trust these automatically generated tarballs and patches, or whether they want to change their process to continue to use PGP-verifiable tags directly from the git tree. Переглянути повний текст статті

All kernel releases are cryptographically signed using OpenPGP-compliant signatures. Everyone is strongly encouraged to verify the integrity of downloaded kernel releases by verifying the corresponding signatures. Basic concepts Every kernel release comes with a cryptographic signature from the person making the release. This cryptographic signature allows anyone to verify whether the files have been modified or otherwise tampered with after the developer created and signed them. The signing and verification process uses public-key cryptography and it is next to impossible to forge a PGP signature without first gaining access to the developer's private key. If this does happen, the developers will revoke the compromised key and will re-sign all their previously signed releases with the new key. To learn more about the way PGP works, please consult Wikipedia. Kernel.org web of trust PGP keys used by members of kernel.org are cross-signed by other members of the Linux kernel development community (and, frequently, by many other people). If you wanted to verify the validity of any key belonging to a member of kernel.org, you could review the list of signatures on their public key and then make a decision whether you trust that key or not. See the Wikipedia article on the subject of the Web of Trust. Using the Web Key Directory If the task of maintaining your own web of trust is too daunting to you, you can opt to shortcut this process by using the "Trust on First Use" (TOFU) approach and rely on the kernel.org Web Key Directory (WKD). To import keys belonging to many kernel developers, you can use the following command: $ gpg2 --locate-keys [username]@kernel.org For example, to import keys belonging to Linus Torvalds and Greg Kroah-Hartman, you would use: $ gpg2 --locate-keys torvalds@kernel.org gregkh@kernel.org This command will verify the TLS certificate presented by kernel.org before importing these keys into your keyring. Using GnuPG to verify kernel signatures All software released via kernel.org has detached PGP signatures you can use to verify the integrity of your downloads. To illustrate the verification process, let's use Linux 4.6.6 release as a walk-through example. First, use "curl" to download the release and the corresponding signature: $ curl -OL https://www.kernel.org/pub/linux/kernel/v4.x/linux-4.6.6.tar.xz $ curl -OL https://www.kernel.org/pub/linux/kernel/v4.x/linux-4.6.6.tar.sign You will notice that the signature is made against the uncompressed version of the archive. This is done so there is only one signature required for .gz and .xz compressed versions of the release. Start by uncompressing the archive, using unxz in our case: $ unxz linux-4.6.6.tar.xz Now verify the .tar archive against the signature: $ gpg2 --verify linux-4.6.6.tar.sign You can combine these steps into a one-liner: $ xz -cd linux-4.6.6.tar.xz | gpg2 --verify linux-4.6.6.tar.sign - It's possible that you get a "No public key error": gpg: Signature made Wed 10 Aug 2016 06:55:15 AM EDT using RSA key ID 38DBBDC86092693E gpg: Can't check signature: No public key Please use the "gpg2 --locate-keys" command listed above to download the key for Greg Kroah-Hartman and Linus Torvalds and then try again: $ gpg2 --locate-keys torvalds@kernel.org gregkh@kernel.org $ gpg2 --verify linux-4.6.6.tar.sign gpg: Signature made Wed 10 Aug 2016 06:55:15 AM EDT gpg: using RSA key 38DBBDC86092693E gpg: Good signature from "Greg Kroah-Hartman <gregkh@kernel.org>" [unknown] gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 647F 2865 4894 E3BD 4571 99BE 38DB BDC8 6092 693E To make the "WARNING" message go away you can indicate that you choose to trust that key using TOFU: $ gpg2 --tofu-policy good 38DBBDC86092693E $ gpg2 --trust-model tofu --verify linux-4.6.6.tar.sign gpg: Signature made Wed 10 Aug 2016 06:55:15 AM EDT gpg: using RSA key 38DBBDC86092693E gpg: Good signature from "Greg Kroah-Hartman <gregkh@kernel.org>" [full] gpg: gregkh@kernel.org: Verified 1 signature in the past 53 seconds. Encrypted 0 messages. Note that you may have to pass "--trust-model tofu" the first time you run the verify command, but it should not be necessary after that. The scripted version If you need to perform this task in an automated environment or simply prefer a more convenient tool, you can use the following helper script to properly download and verify Linux kernel tarballs: get-verified-tarball Please review the script before adopting it for your needs. Important fingerprints Here are key fingerprints for Linus Torvalds, Greg Kroah-Hartman, Sasha Levin, and Ben Hutchings, who are most likely to be releasing kernels: Developer Fingerprint Linus Torvalds ABAF 11C6 5A29 70B1 30AB E3C4 79BE 3E43 0041 1886 Greg Kroah-Hartman 647F 2865 4894 E3BD 4571 99BE 38DB BDC8 6092 693E Sasha Levin E27E 5D8A 3403 A2EF 6687 3BBC DEA6 6FF7 9777 2CDC Ben Hutchings AC2B 29BD 34A6 AFDD B3F6 8F35 E7BF C8EC 9586 1109 Please verify the TLS certificate for this site in your browser before trusting the above information. If you get "BAD signature" If at any time you see "BAD signature" output from "gpg2 --verify", please first check the following first: Make sure that you are verifying the signature against the .tar version of the archive, not the compressed (.tar.xz) version. Make sure the the downloaded file is correct and not truncated or otherwise corrupted. If you repeatedly get the same "BAD signature" output, please email helpdesk@kernel.org, so we can investigate the problem. Kernel.org checksum autosigner and sha256sums.asc We have a dedicated off-the-network system that connects directly to our central attached storage and calculates checksums for all uploaded software releases. The generated sha256sums.asc file is then signed with a PGP key generated for this purpose and that doesn't exist outside of that system. These checksums are NOT intended to replace developer signatures. It is merely a way for someone to quickly verify whether contents on one of the many kernel.org mirrors match the contents on the master mirror. While you may use them to quickly verify whether what you have downloaded matches what we have on our central storage system, you should continue to use developer signatures for best assurance. Kernel releases prior to September, 2011 Prior to September, 2011 all kernel releases were signed automatically by the same PGP key: pub 1024D/517D0F0E 2000-10-10 [revoked: 2011-12-11] Key fingerprint = C75D C40A 11D7 AF88 9981 ED5B C86B A06A 517D 0F0E uid Linux Kernel Archives Verification Key <ftpadmin@kernel.org> Due to the kernel.org systems compromise, this key has been retired and revoked. It will no longer be used to sign future releases and you should NOT use this key to verify the integrity of any archives. It is almost certain that this key has fallen into malicious hands. All kernel releases that were previously signed with this key were cross-checked and signed with another key, created specifically for this purpose: pub 3072R/C4790F9D 2013-08-08 Key fingerprint = BFA7 DD3E 0D42 1C9D B6AB 6527 0D3B 3537 C479 0F9D uid Linux Kernel Archives Verification Key (One-off resigning of old releases) <ftpadmin@kernel.org> The private key used for this purpose has been destroyed and cannot be used to sign any releases produced after 2011. Переглянути повний текст статті

The Linux Foundation IT team has been working to improve the code integrity of git repositories hosted at kernel.org by promoting the use of PGP-signed git tags and commits. Doing so allows anyone to easily verify that git repositories have not been altered or tampered with no matter from which worldwide mirror they may have been cloned. If the digital signature on your cloned repository matches the PGP key belonging to Linus Torvalds or any other maintainer, then you can be assured that what you have on your computer is the exact replica of the kernel code without any omissions or additions. To help promote the use of PGP signatures in Linux kernel development, we now offer a detailed guide within the kernel documentation tree: Kernel Maintainer PGP Guide Further, we are happy to announce a new special program sponsored by The Linux Foundation in partnership with Nitrokey -- the developer and manufacturer of smartcard-compatible digital tokens capable of storing private keys and performing PGP operations on-chip. Under this program, any developer who is listed as a maintainer in the MAINTAINERS file, or who has a kernel.org account can qualify for a free digital token to help improve the security of their PGP keys. The cost of the device, including any taxes, shipping and handling will be covered by The Linux Foundation. To participate in this program, please access the special store front on the Nitrokey website: Nitrokey Start for Kernel Developers Who qualifies for this program? To qualify for the program, you need to have an account at kernel.org or have your email address listed in the MAINTAINERS file (following the "M:" heading). If you do not currently qualify but think you should, the easiest course of action is to get yourself added to the MAINTAINERS file or to apply for an account at kernel.org. Which devices are available under this program? The program is limited to Nitrokey Start devices. There are several reasons why we picked this particular device among several available options. First of all, many Linux kernel developers have a strong preference not just for open-source software, but for open hardware as well. Nitrokey is one of the few companies selling GnuPG-compatible smartcard devices that provide both, since Nitrokey Start is based on Gnuk cryptographic token firmware developed by Free Software Initiative of Japan. It is also one of the few commercially available devices that offer native support for ECC keys, which are both faster computationally than large RSA keys and generate smaller digital signatures. With our push to use more code signing of git objects themselves, both the open nature of the device and its support for fast modern cryptography were key points in our evaluation. Additionally, Nitrokey devices (both Start and Pro models) are already used by open-source developers for cryptographic purposes and they are known to work well with Linux workstations. What is the benefit of digital smartcard tokens? With usual GnuPG operations, the private keys are stored in the home directory where they can be stolen by malware or exposed via other means, such as poorly secured backups. Furthermore, each time a GnuPG operation is performed, the keys are loaded into system memory and can be stolen from there using sufficiently advanced techniques (the likes of Meltdown and Spectre). A digital smartcard token like Nitrokey Start contains a cryptographic chip that is capable of storing private keys and performing crypto operations directly on the token itself. Because the key contents never leave the device, the operating system of the computer into which the token is plugged in is not able to retrieve the private keys themselves, therefore significantly limiting the ways in which the keys can be leaked or stolen. Questions or problems? If you qualify for the program, but encounter any difficulties purchasing the device, please contact Nitrokey at shop@nitrokey.com. For any questions about the program itself or with any other comments, please reach out to info@linuxfoundation.org. Переглянути повний текст статті

If you are in charge of CI infrastructure that needs to perform frequent full clones of kernel trees from git.kernel.org, we strongly recommend that you use the git bundles we provide instead of performing a full clone directly from git repositories. It is better for you, because downloading the bundle from CDN is probably going to be much faster for you than cloning from our frontends due to the CDN being more local. You can even copy the bundle to a fileserver on your local infrastructure and save a lot of repeated external traffic. It is better for us, because if you first clone from the bundle, you only need to fetch a handful of newer objects directly from git.kernel.org frontends. This not only uses an order of magnitude less bandwidth, but also results in a much smaller memory footprint on our systems -- git daemon needs a lot of RAM when serving full clones of linux repositories. Here is a simple script that will help you automate the process of first downloading the git bundle and then fetching the newer objects: linux-bundle-clone Thank you for helping us keep our systems fast and accessible to all. Переглянути повний текст статті

We'd like to announce several small changes to the way Linux tarballs are produced. Mainline release tarball signatures Starting with the 4.18 final release, all mainline tarball PGP signatures will be made by Greg Kroah-Hartman instead of Linus Torvalds. The main goal behind this change is to simplify the verification process and make all kernel tarball releases available for download on kernel.org be signed by the same developer. Linus Torvalds will continue to PGP-sign all tags in the mainline git repository. They can be verified using the git verify-tag command. Sunsetting .gz tarball generation We stopped creating .bz2 copies of tarball releases 5 years ago, and the time has come to stop producing .gz duplicate copies of all our content as well, as XZ tools and libraries are now available on all major platforms. Starting September 1st, 2018, all tarball releases available via /pub download locations will only be available in XZ-compressed format. If you absolutely must have .gz compressed tarballs, you may obtain them from git.kernel.org by following snapshot download links in the appropriate repository view. No future PGP signatures on patches and changelogs For legacy purposes, we will continue to provide pre-generated changelogs and patches (both to the previous mainline and incremental patches to previous stable). However, from now on they will be generated by automated processes and will no longer carry detached PGP signatures. If you require cryptographically verified patches, please generate them directly from the stable git repository after verifying the PGP signatures on the tags using git verify-tag. Переглянути повний текст статті

We are trialing out a new feature that can send you a notification when the patches you send to the LKML are applied to linux-next or to the mainline git trees. If you are interested in trying it out, here are the details: The patches must be sent to the LKML (linux-kernel@vger.kernel.org). One of the cc's must be notify@kernel.org (Bcc will not work). Alternatively, there should be a "X-Patchwork-Bot: notify" email header. The patches must not have been modified by the maintainer(s). All patches in the series must have been applied, not just some of them. The last two points are important, because if there are changes between the content of the patch as it was first sent to the mailing list, and how it looks like by the time it is applied to linux-next or mainline, the bot will not be able to recognize it as the same patch. Similarly, for series of multiple patches, the bot must be able to successfully match all patches in the series in order for the notification to go out. If you are using git-format-patch, it is best to add the special header instead of using the Cc notification address, so as to avoid any unnecessary email traffic: --add-header="X-Patchwork-Bot: notify" You should receive one notification email per each patch series, so if you send a series of 20 patches, you will get a single email in the form of a reply to the cover letter, or to the first patch in the series. The notification will be sent directly to you, ignoring any other addresses in the Cc field. The bot uses our LKML patchwork instance to perform matching and tracking, and the source code for the bot is also available if you would like to suggest improvements. nПереглянути повний текст статті

If you are a developer located around Beijing, or if your connection to Beijing is faster and more reliable than to locations outside of China, then you may benefit from the new git.kernel.org mirror kindly provided by Code Aurora Forum at https://kernel.source.codeaurora.cn/. This is a full mirror that is updated just as frequently as other git.kernel.org nodes (in fact, it is managed by the same team as the rest of kernel.org infrastructure, since CAF is part of Linux Foundation IT projects). To start using the Beijing mirror, simply clone from that location or add a separate remote to your existing checkouts, e.g.: git remote add beijing git://kernel.source.codeaurora.cn/pub/scm/.../linux.git git fetch beijing master You may also use http:// and https:// protocols if that makes it easier behind corporate firewalls. nПереглянути повний текст статті

We are pleased to announce the availability of a new mailing list service running under the new lists.linux.dev domain. The goal of this deployment is to offer a subscription service that: prioritizes mail delivery to public-inbox archives available via lore.kernel.org conforms to DMARC requirements to ensure subscriber delivery makes minimal changes to email headers and no changes to the message body content for the purposes of preserving patch attestation If you would like to host a Linux development mailing list on this platform, please see further details on the subspace.kernel.org site. Why another mailing list service? Linux development started in 1991 and has been ongoing for the past 30 years at an ever-increasing pace. Many popular code collaboration platforms have risen throughout these three decades -- and while some of them are still around, many others have shut down and disappeared without offering any way to preserve the history of the projects they used to host. Development via mailed-in patches remains the only widely used mechanism for code collaboration that does not rely on centralized infrastructure maintained by any single entity. The Linux developer community sees transparency, independence and decentralization as core guiding principles behind Linux development, so it has deliberately chosen to continue using email for all its past and ongoing collaboration efforts. What about vger.kernel.org? The infrastructure behind lists.linux.dev supports multiple domains, so all mailing lists hosted on vger.kernel.org will be carefully migrated to the same platform while preserving current addresses, subscribers, and list ids. The only thing that will noticeably change is the procedure to subscribe and unsubscribe from individual lists. As majordomo is no longer maintained, we will instead switch to using separate subscribe/unsusbscribe addresses per each list. There are no firm ETAs for this migration, but if you are currently subscribed to any mailing list hosted on vger.kernel.org, you will receive a message when the migration date is approaching. nПереглянути повний текст статті

Email is the only reliable way of contacting Kernel.org administrators. General contacts helpdesk@kernel.org: All questions about kernel.org infrastructure. Please do not send general Linux questions or bug reports to these addresses. We do not have the resources to reply to them. Please try the following sites for general Linux help: https://superuser.com/ - for computer enthusiasts and power users https://serverfault.com/ - for systems administrators https://askubuntu.com/ - for users of Ubuntu Linux Linux Foundation also offers training opportunities if you are interested in learning more about Linux, want to become a more proficient Linux systems administrator, or want to know more about how Linux can help your company succeed. https://training.linuxfoundation.org/ Mailing address Please send any mail correspondence to the Linux Foundation: The Linux Foundation 1 Letterman Drive Building D, Suite D4700 San Francisco, CA 94129 Phone/Fax: +1 415 723 9709 nПереглянути повний текст статті

If you have questions, comments or concerns about the F.A.Q. please contact us at helpdesk@kernel.org. Is Linux Kernel Free Software? Linux kernel is released under the terms of GNU GPL version 2 and is therefore Free Software as defined by the Free Software Foundation. For more information, please consult the documentation: Linux kernel licensing rules I heard that Linux ships with non-free "blobs" Before many devices are able to communicate with the OS, they must first be initialized with the "firmware" provided by the device manufacturer. This firmware is not part of Linux and isn't "executed" by the kernel -- it is merely uploaded to the device during the driver initialization stage. While some firmware images are built from free software, a large subset of it is only available for redistribution in binary-only form. To avoid any licensing confusion, firmware blobs were moved from the main Linux tree into a separate repository called linux-firmware. It is possible to use Linux without any non-free firmware binaries, but usually at the cost of rendering a lot of hardware inoperable. Furthermore, many devices that do not require a firmware blob during driver initialization simply already come with non-free firmware preinstalled on them. If your goal is to run a 100% free-as-in-freedom setup, you will often need to go a lot further than just avoiding loadable binary-only firmware blobs. Can I use the word "Linux" or the Tux logo? Linux is a registered trademark of Linus Torvalds and its use is governed by the Linux Trademark Institute. Please consult the following page for further information: Trademark Usage The Tux penguin logo was created by Larry Ewing using Gimp software. It is free to use, including commercially, as long as you give Larry Ewing proper credit ("if someone asks"). For any other permissions, please reach out to Mr. Larry Ewing directly. What does "stable/EOL" and "longterm" mean? As kernels move from the "mainline" into the "stable" category, two things can happen: They can reach "End of Life" after a few bugfix revisions, which means that kernel maintainers will release no more bugfixes for this kernel version, or They can be put into "longterm" maintenance, which means that maintainers will provide bugfixes for this kernel revision for a much longer period of time. If the kernel version you are using is marked "EOL," you should consider upgrading to the next major version as there will be no more bugfixes provided for the kernel version you are using. Please check the Releases page for more info. Why is an LTS kernel marked as "stable" on the front page? Long-term support ("LTS") kernels announced on the Releases page will be marked as "stable" on the front page if there are no other current stable kernel releases. This is done to avoid breaking automated parsers monitoring kernel.org with an expectation that there will always be a kernel release marked as "stable." Linus has tagged a new release, but it's not listed on the front page! Linus Torvalds PGP-signs git repository tags for all new mainline kernel releases, however a separate set of PGP signatures needs to be generated by the stable release team in order to create downloadable tarballs. Due to timezone differences between Linus and the members of the stable team, there is usually a delay of several hours between when the new mainline release is tagged and when PGP-signed tarballs become available. The front page is updated once that process is completed. Is there an RSS feed for the latest kernel version? Yes, and you can find it at https://www.kernel.org/feeds/kdist.xml. We also publish a .json file with the latest release information, which you can pull from here: https://www.kernel.org/releases.json. Where can I find kernel 3.10.0-1160.45.1.foo? Kernel versions that have a dash in them are packaged by distributions and are often extensively modified. Please contact the relevant distribution to obtain the exact kernel source. See the Releases page for more info on distribution kernels. How do I report a problem with the kernel? If you are running a kernel that came with your Linux distribution, then the right place to start is by reporting the problem through your distribution support channels. Here are a few popular choices: Ubuntu Fedora Project Arch Linux Linux Mint Debian GNU/Linux Red Hat OpenSUSE SUSE If you are sure that the problem is with the upstream kernel, please refer to the following document that describes how to report bugs and regressions to the developers: Reporting issues How do I get involved with Linux Kernel development? A good place to start is the Kernel Newbies website. Can I get an account on kernel.org? Kernel.org accounts are usually reserved for subsystem maintainers or high-profile developers. It is absolutely not necessary to have an account on kernel.org to contribute to the development of the Linux kernel, unless you submit pull requests directly to Linus Torvalds. If you are listed in the MAINTAINERS file or have reasons to believe you should have an account on kernel.org because of the amount of your contributions, please refer to the accounts page for the procedure to follow. nПереглянути повний текст статті

What is Linux? Linux is a clone of the operating system Unix, written from scratch by Linus Torvalds with assistance from a loosely-knit team of hackers across the Net. It aims towards POSIX and Single UNIX Specification compliance. It has all the features you would expect in a modern fully-fledged Unix, including true multitasking, virtual memory, shared libraries, demand loading, shared copy-on-write executables, proper memory management, and multistack networking including IPv4 and IPv6. Although originally developed first for 32-bit x86-based PCs (386 or higher), today Linux also runs on a multitude of other processor architectures, in both 32- and 64-bit variants. New to Linux? If you're new to Linux, you don't want to download the kernel, which is just a component in a working Linux system. Instead, you want what is called a distribution of Linux, which is a complete Linux system. There are numerous distributions available for download on the Internet as well as for purchase from various vendors; some are general-purpose, and some are optimized for specific uses. We currently have mirrors of several distributions available at https://mirrors.kernel.org/. Note, however, that most distributions are very large (several gigabytes), so unless you have a fast Internet link you may want to save yourself some hassle and purchase a CD-ROM with a distribution; such CD-ROMs are available from a number of vendors. Mailing lists The Linux kernel is discussed on the linux-kernel mailing list at vger.kernel.org. Please read the FAQ before subscribing. Although there is no official archive site, unofficial archives of the list can be found at: https://lkml.org/ https://marc.info/?l=linux-kernel nПереглянути повний текст статті

The Linux Kernel Organization is a California Public Benefit Corporation established in 2002 to distribute the Linux kernel and other Open Source software to the public without charge. We are recognized by the IRS as a 501(c)3 private operating foundation. IRS determination letter California determination letter The Linux Kernel Organization is managed by The Linux Foundation, which provides full technical, financial and staffing support for running and maintaining the kernel.org infrastructure. Legal information Due to U.S. Exports Regulations, all cryptographic software on this site is subject to the following legal notice: This site includes publicly available encryption source code which, together with object code resulting from the compiling of publicly available source code, may be exported from the United States under License Exception "TSU" pursuant to 15 C.F.R. Section 740.13(e). This legal notice applies to cryptographic software only. Please see the Bureau of Industry and Security for more information about current U.S. regulations. Our servers are located in Corvallis, Oregon, USA; Palo Alto and San Francisco, California, USA; Portland, Oregon, USA; and Montréal, Québec, Canada. Use in violation of any applicable laws is prohibited. Linux is a Registered Trademark of Linus Torvalds. All trademarks are property of their respective owners. nПереглянути повний текст статті