From: Zhong Jianxin Date: Thu, 12 May 2016 02:52:21 +0000 (+0800) Subject: Move pages to top folder X-Git-Url: http://git.lede-project.org./?a=commitdiff_plain;h=312bed6fbe82082be9eeeaee3d13316bd27341a2;p=web.git Move pages to top folder --- diff --git a/about.txt b/about.txt new file mode 100644 index 0000000..308d074 --- /dev/null +++ b/about.txt @@ -0,0 +1,33 @@ +About the LEDE project +====================== + +include::menu.inc[] + +== Name + +image:logo/logo.png["The LEDE logo",role="left"] +The name _LEDE_ is an abbreviation for Linux Embedded Development Environment, +a reference to its flexibility and embedded buildroot origins, making it a +solid choice for embedded Linux applications far beyond the wireless router +and network appliance realm. + +== People + +Here you can find an alphabetically ordered list of the current people involved in _LEDE_ development: + +[cols="2*1",options="header"] +|==== +| Real Name | Nickname +| Alexander Couzens | lynxis +| Álvaro Fernández Rojas | noltari +| Daniel Golle | dangole +| Felix Fietkau | nbd +| Hauke Mehrtens | hauke +| Jo-Philipp Wich | jow +| John Crispin | blogic +| Matthias Schiffer | neoraider +| Rafał Miłecki | rmilecki +| Steven Barth | cyrus +| Stijn Tintel | stintel +| Ted Hess | thess +|==== diff --git a/communication.txt b/communication.txt new file mode 100644 index 0000000..1b9e36f --- /dev/null +++ b/communication.txt @@ -0,0 +1,65 @@ +Project Communication +===================== + +include::menu.inc[] + +== Communication + +It is possible to communicate with other community members using mail and IRC. +All project related communication should be done on public channels that are +archived and easily browsable. Specific problems and tasks may be resolved +using direct means of communication. + + +=== Mailing Lists + +The project offers the following mailing lists + +. http://lists.infradead.org/mailman/listinfo/lede-dev[lede-dev@lists.infradead.org] - + This list is used for submitting patches and general development related work +. http://lists.infradead.org/mailman/listinfo/lede-adm[lede-adm@lists.infradead.org] - + This list is used for project organisational purposes. Anyone can + subscribe and read this list, only committers may write to this list. + + +=== IRC Channels + +The project provides 2 IRC channels on freenode + +. #lede-dev - a public channel for everyone to join and participate +. #lede-adm - a moderated channel that anyone can join but only people with +v flag can write on + + +=== Twitter + +In case of services going down, being moved or being unreachable for any other +reason, please go to twitter and see what the status is. The project will do +its best to post updates link:https://twitter.com/lede_project[here] + + +=== Corporate Contact + +There is a special email address that companies wanting to collaborate with the +project can use to contact committers confidentially. These types of "first contact" +only have the purpose of helping companies understand the mode of operations. Once the +intent is communicated, companies are invited to participate in the project just +like any other community member. This means that engagement should be done in +public. Ideally companies simply allow part of their R&D team to participate +in the normal development process as normal community members. There will be +no special treatment beyond the "first contact". Please see the project +link:rules.html[rules] for further information. + +== Project Meetings + +We attempt to have regular IRC meetings to discuss and decide project matters. + +=== Next Meeting + +The next meeting date is yet to be decided. + +For the agenda of the upcoming meeting refer to the +http://piratepad.net/ep/pad/view/ro.UdKV08dIlKx/latest[agenda pad]. + +== Meeting Logs + +All meeting logs can be viewed under http://meetings.lede-project.org/lede-adm/[here] diff --git a/development.txt b/development.txt new file mode 100644 index 0000000..83b3c83 --- /dev/null +++ b/development.txt @@ -0,0 +1,146 @@ +Development +=========== + +include::menu.inc[] + +== The Source Code + +The LEDE project source code starts off with OpenWrt revision r49258. The code +is stored inside a git tree which contains all branches and releases ever made +by OpenWrt. While importing the sources the tree was normalised and some +minor tweaks were made to committer names and mail addresses. + +All repositories can be browsed online through +http://git.lede-project.org/[Gitweb] as well. + +=== Getting The _LEDE_ Code + +Any _LEDE_ development happens in the main +source.git+ repository which is +accessible via both HTTP and HTTPS: + +---- +git clone http://git.lede-project.org/source.git +---- + +You can find a mirror of the repository on Github: + +---- +git clone https://github.com/lede-project/source.git +---- + +=== Getting the OpenWrt Code + +We keep the original OpenWrt source code up to +https://git.lede-project.org/?p=openwrt/source.git;a=commit;h=ee53a240ac902dc83209008a2671e7fdcf55957a[r49258] +available, mostly as reference and for historic interest. + +The original OpenWrt Subversion repository has been split up into several Git +repositories mapping the various SVN directories and tags to proper Git +branches. + +---- +git clone http://git.lede-project.org/openwrt/source.git +git clone http://git.lede-project.org/openwrt/packages.git +git clone http://git.lede-project.org/openwrt/feeds.git +git clone http://git.lede-project.org/openwrt/docs.git +---- + +=== The Web Presence + +The pages you're reading are generated from text files using the +http://www.methods.co.nz/asciidoc/[AsciiDoc] suite. Any changes made to the +projects web site will be reflected in our +web.git+ repository: + +---- +git clone http://git.lede-project.org/web.git +---- + +=== Submitting Patches + +The biggest difference is that we now accept pull requests. The tree that shall +be pulled from needs to be hosted publicly. Small fixes and minor patches can +also be submitted via the +http://lists.infradead.org/mailman/listinfo/lede-dev[development mailing list]. +Submissions should follow these rules + +. TBD + +All patches need to be sent in a format that they are listed in http://patchwork.ozlabs.org/project/lede/list/[patchwork]. +If the patch does not get listed in patchwork then it won't get processed. + + +=== Reporting Bugs + +. *All* bug reports need to be submitted via the + http://lists.infradead.org/mailman/listinfo/lede-dev[development mailing list] +. When reporting bugs please make sure to + .. Name the tree/revision + .. Name the affected device + .. What does it do that it should not do / what does it not do that it should do + .. Steps to reproduce + .. What you have already done to fix the problem + .. Any additional info you thinks is important +. Reporting a bug means that you reported a bug. It does not constitute a claim that + anyone has to work on fixing it. +. Pointless/vague/silly/... bugs reports will be ignored +. Feature requests are not Bugs. They will also be ignored. +. The better your bug report, the more likely it is that it will be worked on. + +All bug reports need to be sent in a format so that they are listed in the issue +tracker (__LINK__). If the bug report does not get listed in the issue tracker then +it won't get processed. + + +=== Patch Merging And Tree Life Cycle + +We encourage committers to host their own staging trees where they aggregate patches +that they feel responsible for and/or ones that they created themselves. Once the tree +has been reviewed and tested it can be proposed for inclusion in the master branch. + +. Trees will be merged into master at any time +. Bug fixes can be merged into master directly +. PRs can be sent to the patches mailing list from any source and will always be considered + for inclusion if the quality of the tree is good and format of submission is correct +. Staging trees can be hosted as part of the projects git infrastucture, private servers, ... + +=== Kernel updates + +It has proven impractical and a time killer to always be on the very latest kernel within +2 days of its release. It has caused these issues. + +. diversification of kernel versions +. pressure on maintainers to constantly upgrade rather than stabilise +. huge effort invested to upgrade 3-4 times between releases +. huge workload to maintain kmod-* packaging +. Upgrade to kernels that might not be fully tested + +This is obviously not an invite to sit on ancient and dusty kernels. A sane path in between +should be taken that give the community recent kernels without causing unnecessary workload +and stability issues. + +There should be a max of three concurrent kernel version. Having only two concurrent versions +is better than three. + +In Short - stability should be valued higher than bleeding edge, although bleeding edge is +also important, but not as a trade-off to stability. + + +=== Releases + +Generating Releases has already been vastly automated. The remaining parts of the process need +to also be automated before the first _LEDE_ release. We will introduce a TESTERS file that is +formatted similarly to the MAINTAINERS file of the kernel. Community members can list themselves +as testers for a target/profile/device. Once a release has been generated testers should receive +an email informing them of the requirement for images to be tested. It needs to be decided if only +tested images should be included in the binary release. + +Releases should + +. Happen at least once a year +. Have at least one maintenance update +. Provide CVE/critical/... fixes for at least one year after the release +. Only include maintained targets +. Only include targets that have seen on device testing +. Be ready when they are ready + +See the TODO page for more info. diff --git a/downloads.txt b/downloads.txt new file mode 100644 index 0000000..10d2834 --- /dev/null +++ b/downloads.txt @@ -0,0 +1,51 @@ +Downloads +========= + +include::menu.inc[] + +== Snapshot builds + +The current master branch is regularly processed by a buildbot setup and the +resulting images can be found on https://downloads.lede-project.org/snapshots/targets/ + +You can find the BuildBots activity in the following links: + +* Phase 1: http://phase1.builds.lede-project.org/builders[target/subtargets] +* Phase 2: http://phase2.builds.lede-project.org/builders[packages] + +=== Mirrors + +The contents of the download server are available on several mirrors as well. +Please refer to the list below for alternative locations. + +. *Germany* + + [http://ftp.halifax.rwth-aachen.de/lede/[HTTP]] [ftp://ftp.halifax.rwth-aachen.de/lede/[FTP]] [link:rsync://ftp.halifax.rwth-aachen.de/lede/[RSYNC]] + + ~Sponsored by http://www.rwth-aachen.de/[RWTH Aachen]~ +. *Romania* + + [http://mirrors.linux.ro/lede/downloads/[HTTP]] [ftp://mirrors.linux.ro/lede/downloads/[FTP]] [link:rsync://mirrors.linux.ro/lede/downloads/[RSYNC]] + + ~Sponsored by http://www.rcs-rds.ro[RCS&RDS]~ +. *France* + + [http://lede-project.tetaneutral.net/[HTTP]] [link:rsync://lede-project.tetaneutral.net/downloads/[RSYNC]] + + ~Sponsored by http://tetaneutral.net/[tetaneutral.net]~ +. *Netherlands* + + [http://ftp.snt.utwente.nl/pub/software/lede/[HTTP]] [ftp://ftp.snt.utwente.nl/pub/software/lede/[FTP]] + + ~Sponsored by the https://www.utwente.nl/[SNT, University of Twente]~ + +=== How to mirror + +Please use `rsync://downloads.lede-project.org/downloads` to obtain a copy of +the download repository. + +Syncing the downloads share every 12 to 24 hours hours is ideal. Once a mirror +has been set up, feel free to announce it at `lede-adm@lists.lede-project.org` +so that it can be published on this page. + +The data volume of the snapshots is roughly 35GB, we expect it to grow by +30-40GB with each release. Due to current bandwidth constraints we kindly ask +you to use something like `rsync --bwlimit 8000` when initially pulling the +data. + +=== Sources + +Any source code archives fetched by the buildbots during the build process are +available at http://sources.lede-project.org/ diff --git a/index.txt b/index.txt new file mode 100644 index 0000000..c6f8a85 --- /dev/null +++ b/index.txt @@ -0,0 +1,43 @@ +Welcome to the LEDE project +=========================== + +include::menu.inc[] + +== Introducing the LEDE project - A reboot of the OpenWrt community + +The LEDE project is founded as a spin-off of the OpenWrt project and shares many of the same goals. +We are building an embedded Linux distribution that makes it easy for developers, system administrators or other Linux enthusiasts to build and customize software for embedded devices, especially wireless routers. +The name 'LEDE' stands for 'Linux Embedded Development Environment'. + +Members of the project already include a significant share of the most active members of the OpenWrt community. +We intend to bring new life to Embedded Linux development by creating a community with a strong focus on transparency, collaboration and decentralisation. + +LEDE’s stated goals are: + +* Building a great embedded Linux distribution with focus on stability and functionality. +* Having regular, predictable release cycles coupled with community provided device testing feedback. +* Establishing transparent decision processes with broad community participation and public meetings. + +We decided to create this new project because of long standing issues that we were unable to fix from within the OpenWrt project/community: + +. Number of active core developers at an all time low, no process for getting more new people involved. +. Unreliable infrastructure, fixes prevented by internal disagreements and single points of failure. +. Lack of communication, transparency and coordination in the OpenWrt project, both inside the core team and between the core team and the rest of the community. +. Not enough people with commit access to handle the incoming flow of patches, too little attention to testing and regular builds. +. Lack of focus on stability and documentation. + +To address these issues we set up the LEDE project in a different way compared to OpenWrt: + +. All our communication channels are public, some read-only to non-members to maintain a good signal-to-noise ratio. +. Our decision making process is more open, with an approximate 50/50 mix of developers and power users with voting rights. +. Our infrastructure is simplified a lot, to ensure that it creates less maintenance work for us. +. We have made our merge policy more liberal, based on our experience with the OpenWrt package github feed. +. We have a strong focus on automated testing combined with a simplified release process. + +=== Endorsement + +The *Wrt community is made up of many great communities all tinkering on their +own mission in improving something on this planet. The Following communities have +kindly decided to endorse this project. Thanks ! + +- image:logo/endorsements/qmp.png[qMp logo] http://qmp.cat/News/31_qMp_endorses_the_LEDE_project["qMp endorses the LEDE project"] diff --git a/keygen.txt b/keygen.txt new file mode 100644 index 0000000..c54e6a8 --- /dev/null +++ b/keygen.txt @@ -0,0 +1,341 @@ +Key Generation +============== + +include::menu.inc[] + +== Generate GPG signing key pair + +The guide will explain how to generate a new key pair, how to create a +signing sub key and how to strip the secret master key to avoid leaking +your primary secret key identity in case your signing key (or the entire ++~/.gnupg/+) ever gets lost. + + +=== 1) Generate new, fresh key pair on a secure machine + +---- +$ mkdir /tmp/signing +$ chmod 0700 /tmp/signing +$ gpg --homedir /tmp/signing --gen-key +gpg (GnuPG) 1.4.18; Copyright (C) 2014 Free Software Foundation, Inc. +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. + +gpg: keyring `/tmp/signing/secring.gpg' created +gpg: keyring `/tmp/signing/pubring.gpg' created +---- + +TIP: Pick 4 to generate an RSA-only key and choose a key size of 4096 bits. + For this how-to I choose to set no expiry at all. + +---- +Please select what kind of key you want: + (1) RSA and RSA (default) + (2) DSA and Elgamal + (3) DSA (sign only) + (4) RSA (sign only) +Your selection? 4 +RSA keys may be between 1024 and 4096 bits long. +What keysize do you want? (2048) 4096 +Requested keysize is 4096 bits +Please specify how long the key should be valid. + 0 = key does not expire + = key expires in n days + w = key expires in n weeks + m = key expires in n months + y = key expires in n years +Key is valid for? (0) +Key does not expire at all +Is this correct? (y/N) y +---- + +TIP: GPG will ask about your user identity now, provide your real name and + the mail address you intend to use for your project communication. + I also suggest to provide a meaningful comment, eg. "LEDE Signing Key" + + +---- +You need a user ID to identify your key; the software constructs the user ID +from the Real Name, Comment and Email Address in this form: + "Heinrich Heine (Der Dichter) " + +Real name: Jo-Philipp Wich +Email address: jo@mein.io +Comment: LEDE Signing Key +You selected this USER-ID: + "Jo-Philipp Wich (LEDE Signing Key) " + +Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O +You need a Passphrase to protect your secret key. +---- + +TIP: At this point enter a good pass phrase twice to protect your secret + key, the command will take a while to gather entropy and complete key + until it'll eventually print the key summary: + +---- +gpg: /tmp/signing/trustdb.gpg: trustdb created +gpg: key 612A0E98 marked as ultimately trusted +public and secret key created and signed. + +gpg: checking the trustdb +gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model +gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u +pub 4096R/612A0E98 2016-04-05 + Key fingerprint = 69B2 6A27 62D0 65E6 6F59 6755 C76F DE50 612A 0E98 +uid Jo-Philipp Wich (LEDE Signing Key) + +Note that this key cannot be used for encryption. You may want to use +the command "--edit-key" to generate a subkey for this purpose. +---- + +=== 2) Generate a sub key + +---- +$ gpg --homedir /tmp/signing --edit-key jo@mein.io +gpg (GnuPG) 1.4.18; Copyright (C) 2014 Free Software Foundation, Inc. +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. + +Secret key is available. + +pub 4096R/612A0E98 created: 2016-04-05 expires: never usage: SC + trust: ultimate validity: ultimate +[ultimate] (1). Jo-Philipp Wich (LEDE Signing Key) +---- + +TIP: In the now appearing interactive gpg prompt enter "addkey" to create + a new signing subkey. GnuPG will ask your to unlock the master key using + the passphrase you've given in the previous step. + +---- +gpg> addkey +Key is protected. + +You need a passphrase to unlock the secret key for +user: "Jo-Philipp Wich (LEDE Signing Key) " +4096-bit RSA key, ID 612A0E98, created 2016-04-05 + +Please select what kind of key you want: + (3) DSA (sign only) + (4) RSA (sign only) + (5) Elgamal (encrypt only) + (6) RSA (encrypt only) +---- + +TIP: We'll use a signing-only 4096bit RSA key with an validity of two years + +---- +Your selection? 4 +RSA keys may be between 1024 and 4096 bits long. +What keysize do you want? (2048) 4096 +Requested keysize is 4096 bits +Please specify how long the key should be valid. + 0 = key does not expire + = key expires in n days + w = key expires in n weeks + m = key expires in n months + y = key expires in n years +Key is valid for? (0) 730 +Key expires at Thu Apr 5 18:19:42 2018 CEST +Is this correct? (y/N) y +Really create? (y/N) y +---- + +TIP: At this point, GnuPG will start gathering entropy again, running an + "find /" in the background is a good way to speed it up. When done it + will print the sub key summary and return to the prompt. Note the ID + "1584F206" of the subkey, we'll need that in step 4. + +---- +pub 4096R/612A0E98 created: 2016-04-05 expires: never usage: SC + trust: ultimate validity: ultimate +sub 4096R/1584F206 created: 2016-04-05 expires: 2018-04-05 usage: S +[ultimate] (1). Jo-Philipp Wich (LEDE Signing Key) +---- + +TIP: Enter "save" to commit the new key pair and its sub key to disk, the + GnuPG will automatically exit to the shell. + +---- +gpg> save +---- + +=== 3) Put the key into a vault + +At this point it is a good idea to make a *reliable and secure* backup +of the +/tmp/signing/+ directory, I suggest burning it onto a CDROM or +copying it onto a thumb drive which you can safely lock away or hide in +your apartment :) + +=== 4) Export the private sub key only + +We'll now export just the secret sub key since that is all we'll ever +need to sign files. Use the sub key ID from step 2 followed by an +exclamation mark to select the sub key to export: + +---- +$ gpg --homedir /tmp/signing --export-secret-subkeys 1584F206! \ + > /tmp/secret-signing-key.pgp +$ file /tmp/secret-signing-key.pgp +secret-signing-key.pgp: PGP\011Secret Key - 1024b created on Tue Apr 5 +16:08:15 2016 - RSA (Encrypt or Sign) +---- + +=== 5) Import the secret signing sub key into your actual key store + +You can now import the secret signing sub key on any machine you'll use +for signing files in the future. To import the sub key file, pass it to ++gpg --import+ and leave out the alternative homedir argument: + +---- +$ gpg --import /tmp/secret-signing-key.pgp +gpg: key 612A0E98: secret key imported +gpg: key 612A0E98: public key "Jo-Philipp Wich (LEDE Signing Key) +" imported +gpg: Total number processed: 1 +gpg: imported: 1 (RSA: 1) +gpg: secret keys read: 1 +gpg: secret keys imported: 1 +---- + +TIP: You can now issue a "gpg -K" to list all secret keys in your key store, + you should see the key you've imported with a leading "sec#". The hash + mark here indicates that the secret master key is missing, which is what + we want. + +---- +$ gpg -K +/home/jow/.gnupg/secring.gpg + --------------------------- +[...] +sec# 4096R/612A0E98 2016-04-05 +uid Jo-Philipp Wich (LEDE Signing Key) +ssb 4096R/1584F206 2016-04-05 +---- + +TIP: It is time to upload your public key part to a key server now so that + others can easily fetch it by its fingerprint or your chosen mail + address later on. For uploading use the primary key ID printed after + the "sec#" word in the previous command. + +---- +$ gpg --keyserver hkp://pool.sks-keyservers.net --send-keys 612A0E98 +gpg: sending key 612A0E98 to hkp server pool.sks-keyservers.net +---- + +=== 6) Delete original + +Make sure once again that your backup of the +/tmp/signing+ directory is +complete and readable, then remove the secret sub key file and the +entire temporary signing directory: + +---- +$ rm -r /tmp/signing/ +$ rm /tmp/secret-signing-key.pgp +---- + +TIP: You're now done setting up a suitable signing key pair. + +=== 7) Finish + +To export your public key in ASCII format use the following command, +again with the primary ID you've already used for uploading the pubkey. + +Make sure to provide a meaningful comment so that people looking at the +key file know who it belongs to without having to inspect it using GPG +utilities: + +---- +$ gpg --armor --export --no-version \ + --comment="Public key of Jo-Philipp Wich" 612A0E98 +---- + +In order to sign a file with your signing sub key, use the command below: + +---- +$ gpg --no-version -a -b -u 612A0E98 \ + --comment="My signature for something" -o output.sig input.file +---- + +TIP: Use your key ID as filename when adding your public signing key to the + repository: + +---- +$ cd keyring/gpg/ +$ gpg --armor --export --no-version \ + --comment="Public key of Me Myself" 612A0E98 > 612A0E98.asc +$ git add 612A0E98.asc +$ git commit -sm "Add my public key" +$ git push origin master +---- + +== Generate _usign_ key pair + +In order to generate an _usign_ key pair for use in LEDE release and package +repositories, follow the steps below. + +=== 1) Obtain _usign_ + +Clone the _usign_ repository and compile it. Note that the compilation requires +an installed +cmake+ to succeed. + +---- +$ git clone https://git.openwrt.org/project/usign.git +$ cd usign/ +$ cmake . +$ make +---- + +TIP: Run +./usign+ to check that the binary works. + +---- +$ ./usign +Usage: ./usign +Commands: + -V: verify (needs at least -m and -p|-P) + -S: sign (needs at least -m and -s) + -F: print key fingerprint of public/secret key or signature + -G: generate a new keypair +Options: + -c : add comment to keys + -m : message file + -p : public key file (verify/fingerprint only) + -P : public key directory (verify only) + -q: quiet (do not print verification result, use return code only) + -s : secret key file (sign/fingerprint only) + -x : signature file (defaults to .sig) +---- + +=== 2) Generate key pair + +Instruct the +usign+ executable to generate a new key pair and provide a +suitable comment to be able to identify the key file later on. + +---- +./usign -G -c "LEDE usign key of Jo-Philipp Wich" \ + -s secret.key -p public.key +---- + +TIP: Store the +secret.key+ file in a *secure and reliable* location, you'll + need it to sign package repositories in the future. + +=== 3) Add public key to the repository + +Obtain the fingerprint of your public key with the +usign -F+ command and use +it as filename for storing the pubkey in the +keyring.git+ repository: + +---- +$ ./usign -F -p public.key +72a57f2191b211e0 +---- + +TIP: Add the key to Git, using the fingerprint as filename: + +---- +$ cd keyring/usign/ +$ cp /some/where/public.key 72a57f2191b211e0 +$ git add 72a57f2191b211e0 +$ git commit -sm "Add my public usign key" +$ git push origin master +---- diff --git a/menu.inc b/menu.inc new file mode 100644 index 0000000..172625b --- /dev/null +++ b/menu.inc @@ -0,0 +1,9 @@ +[role="menu"] +. pass:attributes[Home] +. pass:attributes[Communication] +. pass:attributes[Rules] +. pass:attributes[Development] +. pass:attributes[Todo] +. pass:attributes[Downloads] +. pass:attributes[Documentation] +. pass:attributes[About] diff --git a/pages/about.txt b/pages/about.txt deleted file mode 100644 index 308d074..0000000 --- a/pages/about.txt +++ /dev/null @@ -1,33 +0,0 @@ -About the LEDE project -====================== - -include::menu.inc[] - -== Name - -image:logo/logo.png["The LEDE logo",role="left"] -The name _LEDE_ is an abbreviation for Linux Embedded Development Environment, -a reference to its flexibility and embedded buildroot origins, making it a -solid choice for embedded Linux applications far beyond the wireless router -and network appliance realm. - -== People - -Here you can find an alphabetically ordered list of the current people involved in _LEDE_ development: - -[cols="2*1",options="header"] -|==== -| Real Name | Nickname -| Alexander Couzens | lynxis -| Álvaro Fernández Rojas | noltari -| Daniel Golle | dangole -| Felix Fietkau | nbd -| Hauke Mehrtens | hauke -| Jo-Philipp Wich | jow -| John Crispin | blogic -| Matthias Schiffer | neoraider -| Rafał Miłecki | rmilecki -| Steven Barth | cyrus -| Stijn Tintel | stintel -| Ted Hess | thess -|==== diff --git a/pages/communication.txt b/pages/communication.txt deleted file mode 100644 index 1b9e36f..0000000 --- a/pages/communication.txt +++ /dev/null @@ -1,65 +0,0 @@ -Project Communication -===================== - -include::menu.inc[] - -== Communication - -It is possible to communicate with other community members using mail and IRC. -All project related communication should be done on public channels that are -archived and easily browsable. Specific problems and tasks may be resolved -using direct means of communication. - - -=== Mailing Lists - -The project offers the following mailing lists - -. http://lists.infradead.org/mailman/listinfo/lede-dev[lede-dev@lists.infradead.org] - - This list is used for submitting patches and general development related work -. http://lists.infradead.org/mailman/listinfo/lede-adm[lede-adm@lists.infradead.org] - - This list is used for project organisational purposes. Anyone can - subscribe and read this list, only committers may write to this list. - - -=== IRC Channels - -The project provides 2 IRC channels on freenode - -. #lede-dev - a public channel for everyone to join and participate -. #lede-adm - a moderated channel that anyone can join but only people with +v flag can write on - - -=== Twitter - -In case of services going down, being moved or being unreachable for any other -reason, please go to twitter and see what the status is. The project will do -its best to post updates link:https://twitter.com/lede_project[here] - - -=== Corporate Contact - -There is a special email address that companies wanting to collaborate with the -project can use to contact committers confidentially. These types of "first contact" -only have the purpose of helping companies understand the mode of operations. Once the -intent is communicated, companies are invited to participate in the project just -like any other community member. This means that engagement should be done in -public. Ideally companies simply allow part of their R&D team to participate -in the normal development process as normal community members. There will be -no special treatment beyond the "first contact". Please see the project -link:rules.html[rules] for further information. - -== Project Meetings - -We attempt to have regular IRC meetings to discuss and decide project matters. - -=== Next Meeting - -The next meeting date is yet to be decided. - -For the agenda of the upcoming meeting refer to the -http://piratepad.net/ep/pad/view/ro.UdKV08dIlKx/latest[agenda pad]. - -== Meeting Logs - -All meeting logs can be viewed under http://meetings.lede-project.org/lede-adm/[here] diff --git a/pages/development.txt b/pages/development.txt deleted file mode 100644 index 83b3c83..0000000 --- a/pages/development.txt +++ /dev/null @@ -1,146 +0,0 @@ -Development -=========== - -include::menu.inc[] - -== The Source Code - -The LEDE project source code starts off with OpenWrt revision r49258. The code -is stored inside a git tree which contains all branches and releases ever made -by OpenWrt. While importing the sources the tree was normalised and some -minor tweaks were made to committer names and mail addresses. - -All repositories can be browsed online through -http://git.lede-project.org/[Gitweb] as well. - -=== Getting The _LEDE_ Code - -Any _LEDE_ development happens in the main +source.git+ repository which is -accessible via both HTTP and HTTPS: - ----- -git clone http://git.lede-project.org/source.git ----- - -You can find a mirror of the repository on Github: - ----- -git clone https://github.com/lede-project/source.git ----- - -=== Getting the OpenWrt Code - -We keep the original OpenWrt source code up to -https://git.lede-project.org/?p=openwrt/source.git;a=commit;h=ee53a240ac902dc83209008a2671e7fdcf55957a[r49258] -available, mostly as reference and for historic interest. - -The original OpenWrt Subversion repository has been split up into several Git -repositories mapping the various SVN directories and tags to proper Git -branches. - ----- -git clone http://git.lede-project.org/openwrt/source.git -git clone http://git.lede-project.org/openwrt/packages.git -git clone http://git.lede-project.org/openwrt/feeds.git -git clone http://git.lede-project.org/openwrt/docs.git ----- - -=== The Web Presence - -The pages you're reading are generated from text files using the -http://www.methods.co.nz/asciidoc/[AsciiDoc] suite. Any changes made to the -projects web site will be reflected in our +web.git+ repository: - ----- -git clone http://git.lede-project.org/web.git ----- - -=== Submitting Patches - -The biggest difference is that we now accept pull requests. The tree that shall -be pulled from needs to be hosted publicly. Small fixes and minor patches can -also be submitted via the -http://lists.infradead.org/mailman/listinfo/lede-dev[development mailing list]. -Submissions should follow these rules - -. TBD - -All patches need to be sent in a format that they are listed in http://patchwork.ozlabs.org/project/lede/list/[patchwork]. -If the patch does not get listed in patchwork then it won't get processed. - - -=== Reporting Bugs - -. *All* bug reports need to be submitted via the - http://lists.infradead.org/mailman/listinfo/lede-dev[development mailing list] -. When reporting bugs please make sure to - .. Name the tree/revision - .. Name the affected device - .. What does it do that it should not do / what does it not do that it should do - .. Steps to reproduce - .. What you have already done to fix the problem - .. Any additional info you thinks is important -. Reporting a bug means that you reported a bug. It does not constitute a claim that - anyone has to work on fixing it. -. Pointless/vague/silly/... bugs reports will be ignored -. Feature requests are not Bugs. They will also be ignored. -. The better your bug report, the more likely it is that it will be worked on. - -All bug reports need to be sent in a format so that they are listed in the issue -tracker (__LINK__). If the bug report does not get listed in the issue tracker then -it won't get processed. - - -=== Patch Merging And Tree Life Cycle - -We encourage committers to host their own staging trees where they aggregate patches -that they feel responsible for and/or ones that they created themselves. Once the tree -has been reviewed and tested it can be proposed for inclusion in the master branch. - -. Trees will be merged into master at any time -. Bug fixes can be merged into master directly -. PRs can be sent to the patches mailing list from any source and will always be considered - for inclusion if the quality of the tree is good and format of submission is correct -. Staging trees can be hosted as part of the projects git infrastucture, private servers, ... - -=== Kernel updates - -It has proven impractical and a time killer to always be on the very latest kernel within -2 days of its release. It has caused these issues. - -. diversification of kernel versions -. pressure on maintainers to constantly upgrade rather than stabilise -. huge effort invested to upgrade 3-4 times between releases -. huge workload to maintain kmod-* packaging -. Upgrade to kernels that might not be fully tested - -This is obviously not an invite to sit on ancient and dusty kernels. A sane path in between -should be taken that give the community recent kernels without causing unnecessary workload -and stability issues. - -There should be a max of three concurrent kernel version. Having only two concurrent versions -is better than three. - -In Short - stability should be valued higher than bleeding edge, although bleeding edge is -also important, but not as a trade-off to stability. - - -=== Releases - -Generating Releases has already been vastly automated. The remaining parts of the process need -to also be automated before the first _LEDE_ release. We will introduce a TESTERS file that is -formatted similarly to the MAINTAINERS file of the kernel. Community members can list themselves -as testers for a target/profile/device. Once a release has been generated testers should receive -an email informing them of the requirement for images to be tested. It needs to be decided if only -tested images should be included in the binary release. - -Releases should - -. Happen at least once a year -. Have at least one maintenance update -. Provide CVE/critical/... fixes for at least one year after the release -. Only include maintained targets -. Only include targets that have seen on device testing -. Be ready when they are ready - -See the TODO page for more info. diff --git a/pages/downloads.txt b/pages/downloads.txt deleted file mode 100644 index 10d2834..0000000 --- a/pages/downloads.txt +++ /dev/null @@ -1,51 +0,0 @@ -Downloads -========= - -include::menu.inc[] - -== Snapshot builds - -The current master branch is regularly processed by a buildbot setup and the -resulting images can be found on https://downloads.lede-project.org/snapshots/targets/ - -You can find the BuildBots activity in the following links: - -* Phase 1: http://phase1.builds.lede-project.org/builders[target/subtargets] -* Phase 2: http://phase2.builds.lede-project.org/builders[packages] - -=== Mirrors - -The contents of the download server are available on several mirrors as well. -Please refer to the list below for alternative locations. - -. *Germany* + - [http://ftp.halifax.rwth-aachen.de/lede/[HTTP]] [ftp://ftp.halifax.rwth-aachen.de/lede/[FTP]] [link:rsync://ftp.halifax.rwth-aachen.de/lede/[RSYNC]] + - ~Sponsored by http://www.rwth-aachen.de/[RWTH Aachen]~ -. *Romania* + - [http://mirrors.linux.ro/lede/downloads/[HTTP]] [ftp://mirrors.linux.ro/lede/downloads/[FTP]] [link:rsync://mirrors.linux.ro/lede/downloads/[RSYNC]] + - ~Sponsored by http://www.rcs-rds.ro[RCS&RDS]~ -. *France* + - [http://lede-project.tetaneutral.net/[HTTP]] [link:rsync://lede-project.tetaneutral.net/downloads/[RSYNC]] + - ~Sponsored by http://tetaneutral.net/[tetaneutral.net]~ -. *Netherlands* + - [http://ftp.snt.utwente.nl/pub/software/lede/[HTTP]] [ftp://ftp.snt.utwente.nl/pub/software/lede/[FTP]] + - ~Sponsored by the https://www.utwente.nl/[SNT, University of Twente]~ - -=== How to mirror - -Please use `rsync://downloads.lede-project.org/downloads` to obtain a copy of -the download repository. - -Syncing the downloads share every 12 to 24 hours hours is ideal. Once a mirror -has been set up, feel free to announce it at `lede-adm@lists.lede-project.org` -so that it can be published on this page. - -The data volume of the snapshots is roughly 35GB, we expect it to grow by -30-40GB with each release. Due to current bandwidth constraints we kindly ask -you to use something like `rsync --bwlimit 8000` when initially pulling the -data. - -=== Sources - -Any source code archives fetched by the buildbots during the build process are -available at http://sources.lede-project.org/ diff --git a/pages/index.txt b/pages/index.txt deleted file mode 100644 index c6f8a85..0000000 --- a/pages/index.txt +++ /dev/null @@ -1,43 +0,0 @@ -Welcome to the LEDE project -=========================== - -include::menu.inc[] - -== Introducing the LEDE project - A reboot of the OpenWrt community - -The LEDE project is founded as a spin-off of the OpenWrt project and shares many of the same goals. -We are building an embedded Linux distribution that makes it easy for developers, system administrators or other Linux enthusiasts to build and customize software for embedded devices, especially wireless routers. -The name 'LEDE' stands for 'Linux Embedded Development Environment'. - -Members of the project already include a significant share of the most active members of the OpenWrt community. -We intend to bring new life to Embedded Linux development by creating a community with a strong focus on transparency, collaboration and decentralisation. - -LEDE’s stated goals are: - -* Building a great embedded Linux distribution with focus on stability and functionality. -* Having regular, predictable release cycles coupled with community provided device testing feedback. -* Establishing transparent decision processes with broad community participation and public meetings. - -We decided to create this new project because of long standing issues that we were unable to fix from within the OpenWrt project/community: - -. Number of active core developers at an all time low, no process for getting more new people involved. -. Unreliable infrastructure, fixes prevented by internal disagreements and single points of failure. -. Lack of communication, transparency and coordination in the OpenWrt project, both inside the core team and between the core team and the rest of the community. -. Not enough people with commit access to handle the incoming flow of patches, too little attention to testing and regular builds. -. Lack of focus on stability and documentation. - -To address these issues we set up the LEDE project in a different way compared to OpenWrt: - -. All our communication channels are public, some read-only to non-members to maintain a good signal-to-noise ratio. -. Our decision making process is more open, with an approximate 50/50 mix of developers and power users with voting rights. -. Our infrastructure is simplified a lot, to ensure that it creates less maintenance work for us. -. We have made our merge policy more liberal, based on our experience with the OpenWrt package github feed. -. We have a strong focus on automated testing combined with a simplified release process. - -=== Endorsement - -The *Wrt community is made up of many great communities all tinkering on their -own mission in improving something on this planet. The Following communities have -kindly decided to endorse this project. Thanks ! - -- image:logo/endorsements/qmp.png[qMp logo] http://qmp.cat/News/31_qMp_endorses_the_LEDE_project["qMp endorses the LEDE project"] diff --git a/pages/keygen.txt b/pages/keygen.txt deleted file mode 100644 index c54e6a8..0000000 --- a/pages/keygen.txt +++ /dev/null @@ -1,341 +0,0 @@ -Key Generation -============== - -include::menu.inc[] - -== Generate GPG signing key pair - -The guide will explain how to generate a new key pair, how to create a -signing sub key and how to strip the secret master key to avoid leaking -your primary secret key identity in case your signing key (or the entire -+~/.gnupg/+) ever gets lost. - - -=== 1) Generate new, fresh key pair on a secure machine - ----- -$ mkdir /tmp/signing -$ chmod 0700 /tmp/signing -$ gpg --homedir /tmp/signing --gen-key -gpg (GnuPG) 1.4.18; Copyright (C) 2014 Free Software Foundation, Inc. -This is free software: you are free to change and redistribute it. -There is NO WARRANTY, to the extent permitted by law. - -gpg: keyring `/tmp/signing/secring.gpg' created -gpg: keyring `/tmp/signing/pubring.gpg' created ----- - -TIP: Pick 4 to generate an RSA-only key and choose a key size of 4096 bits. - For this how-to I choose to set no expiry at all. - ----- -Please select what kind of key you want: - (1) RSA and RSA (default) - (2) DSA and Elgamal - (3) DSA (sign only) - (4) RSA (sign only) -Your selection? 4 -RSA keys may be between 1024 and 4096 bits long. -What keysize do you want? (2048) 4096 -Requested keysize is 4096 bits -Please specify how long the key should be valid. - 0 = key does not expire - = key expires in n days - w = key expires in n weeks - m = key expires in n months - y = key expires in n years -Key is valid for? (0) -Key does not expire at all -Is this correct? (y/N) y ----- - -TIP: GPG will ask about your user identity now, provide your real name and - the mail address you intend to use for your project communication. - I also suggest to provide a meaningful comment, eg. "LEDE Signing Key" - - ----- -You need a user ID to identify your key; the software constructs the user ID -from the Real Name, Comment and Email Address in this form: - "Heinrich Heine (Der Dichter) " - -Real name: Jo-Philipp Wich -Email address: jo@mein.io -Comment: LEDE Signing Key -You selected this USER-ID: - "Jo-Philipp Wich (LEDE Signing Key) " - -Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O -You need a Passphrase to protect your secret key. ----- - -TIP: At this point enter a good pass phrase twice to protect your secret - key, the command will take a while to gather entropy and complete key - until it'll eventually print the key summary: - ----- -gpg: /tmp/signing/trustdb.gpg: trustdb created -gpg: key 612A0E98 marked as ultimately trusted -public and secret key created and signed. - -gpg: checking the trustdb -gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model -gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u -pub 4096R/612A0E98 2016-04-05 - Key fingerprint = 69B2 6A27 62D0 65E6 6F59 6755 C76F DE50 612A 0E98 -uid Jo-Philipp Wich (LEDE Signing Key) - -Note that this key cannot be used for encryption. You may want to use -the command "--edit-key" to generate a subkey for this purpose. ----- - -=== 2) Generate a sub key - ----- -$ gpg --homedir /tmp/signing --edit-key jo@mein.io -gpg (GnuPG) 1.4.18; Copyright (C) 2014 Free Software Foundation, Inc. -This is free software: you are free to change and redistribute it. -There is NO WARRANTY, to the extent permitted by law. - -Secret key is available. - -pub 4096R/612A0E98 created: 2016-04-05 expires: never usage: SC - trust: ultimate validity: ultimate -[ultimate] (1). Jo-Philipp Wich (LEDE Signing Key) ----- - -TIP: In the now appearing interactive gpg prompt enter "addkey" to create - a new signing subkey. GnuPG will ask your to unlock the master key using - the passphrase you've given in the previous step. - ----- -gpg> addkey -Key is protected. - -You need a passphrase to unlock the secret key for -user: "Jo-Philipp Wich (LEDE Signing Key) " -4096-bit RSA key, ID 612A0E98, created 2016-04-05 - -Please select what kind of key you want: - (3) DSA (sign only) - (4) RSA (sign only) - (5) Elgamal (encrypt only) - (6) RSA (encrypt only) ----- - -TIP: We'll use a signing-only 4096bit RSA key with an validity of two years - ----- -Your selection? 4 -RSA keys may be between 1024 and 4096 bits long. -What keysize do you want? (2048) 4096 -Requested keysize is 4096 bits -Please specify how long the key should be valid. - 0 = key does not expire - = key expires in n days - w = key expires in n weeks - m = key expires in n months - y = key expires in n years -Key is valid for? (0) 730 -Key expires at Thu Apr 5 18:19:42 2018 CEST -Is this correct? (y/N) y -Really create? (y/N) y ----- - -TIP: At this point, GnuPG will start gathering entropy again, running an - "find /" in the background is a good way to speed it up. When done it - will print the sub key summary and return to the prompt. Note the ID - "1584F206" of the subkey, we'll need that in step 4. - ----- -pub 4096R/612A0E98 created: 2016-04-05 expires: never usage: SC - trust: ultimate validity: ultimate -sub 4096R/1584F206 created: 2016-04-05 expires: 2018-04-05 usage: S -[ultimate] (1). Jo-Philipp Wich (LEDE Signing Key) ----- - -TIP: Enter "save" to commit the new key pair and its sub key to disk, the - GnuPG will automatically exit to the shell. - ----- -gpg> save ----- - -=== 3) Put the key into a vault - -At this point it is a good idea to make a *reliable and secure* backup -of the +/tmp/signing/+ directory, I suggest burning it onto a CDROM or -copying it onto a thumb drive which you can safely lock away or hide in -your apartment :) - -=== 4) Export the private sub key only - -We'll now export just the secret sub key since that is all we'll ever -need to sign files. Use the sub key ID from step 2 followed by an -exclamation mark to select the sub key to export: - ----- -$ gpg --homedir /tmp/signing --export-secret-subkeys 1584F206! \ - > /tmp/secret-signing-key.pgp -$ file /tmp/secret-signing-key.pgp -secret-signing-key.pgp: PGP\011Secret Key - 1024b created on Tue Apr 5 -16:08:15 2016 - RSA (Encrypt or Sign) ----- - -=== 5) Import the secret signing sub key into your actual key store - -You can now import the secret signing sub key on any machine you'll use -for signing files in the future. To import the sub key file, pass it to -+gpg --import+ and leave out the alternative homedir argument: - ----- -$ gpg --import /tmp/secret-signing-key.pgp -gpg: key 612A0E98: secret key imported -gpg: key 612A0E98: public key "Jo-Philipp Wich (LEDE Signing Key) -" imported -gpg: Total number processed: 1 -gpg: imported: 1 (RSA: 1) -gpg: secret keys read: 1 -gpg: secret keys imported: 1 ----- - -TIP: You can now issue a "gpg -K" to list all secret keys in your key store, - you should see the key you've imported with a leading "sec#". The hash - mark here indicates that the secret master key is missing, which is what - we want. - ----- -$ gpg -K -/home/jow/.gnupg/secring.gpg - --------------------------- -[...] -sec# 4096R/612A0E98 2016-04-05 -uid Jo-Philipp Wich (LEDE Signing Key) -ssb 4096R/1584F206 2016-04-05 ----- - -TIP: It is time to upload your public key part to a key server now so that - others can easily fetch it by its fingerprint or your chosen mail - address later on. For uploading use the primary key ID printed after - the "sec#" word in the previous command. - ----- -$ gpg --keyserver hkp://pool.sks-keyservers.net --send-keys 612A0E98 -gpg: sending key 612A0E98 to hkp server pool.sks-keyservers.net ----- - -=== 6) Delete original - -Make sure once again that your backup of the +/tmp/signing+ directory is -complete and readable, then remove the secret sub key file and the -entire temporary signing directory: - ----- -$ rm -r /tmp/signing/ -$ rm /tmp/secret-signing-key.pgp ----- - -TIP: You're now done setting up a suitable signing key pair. - -=== 7) Finish - -To export your public key in ASCII format use the following command, -again with the primary ID you've already used for uploading the pubkey. - -Make sure to provide a meaningful comment so that people looking at the -key file know who it belongs to without having to inspect it using GPG -utilities: - ----- -$ gpg --armor --export --no-version \ - --comment="Public key of Jo-Philipp Wich" 612A0E98 ----- - -In order to sign a file with your signing sub key, use the command below: - ----- -$ gpg --no-version -a -b -u 612A0E98 \ - --comment="My signature for something" -o output.sig input.file ----- - -TIP: Use your key ID as filename when adding your public signing key to the - repository: - ----- -$ cd keyring/gpg/ -$ gpg --armor --export --no-version \ - --comment="Public key of Me Myself" 612A0E98 > 612A0E98.asc -$ git add 612A0E98.asc -$ git commit -sm "Add my public key" -$ git push origin master ----- - -== Generate _usign_ key pair - -In order to generate an _usign_ key pair for use in LEDE release and package -repositories, follow the steps below. - -=== 1) Obtain _usign_ - -Clone the _usign_ repository and compile it. Note that the compilation requires -an installed +cmake+ to succeed. - ----- -$ git clone https://git.openwrt.org/project/usign.git -$ cd usign/ -$ cmake . -$ make ----- - -TIP: Run +./usign+ to check that the binary works. - ----- -$ ./usign -Usage: ./usign -Commands: - -V: verify (needs at least -m and -p|-P) - -S: sign (needs at least -m and -s) - -F: print key fingerprint of public/secret key or signature - -G: generate a new keypair -Options: - -c : add comment to keys - -m : message file - -p : public key file (verify/fingerprint only) - -P : public key directory (verify only) - -q: quiet (do not print verification result, use return code only) - -s : secret key file (sign/fingerprint only) - -x : signature file (defaults to .sig) ----- - -=== 2) Generate key pair - -Instruct the +usign+ executable to generate a new key pair and provide a -suitable comment to be able to identify the key file later on. - ----- -./usign -G -c "LEDE usign key of Jo-Philipp Wich" \ - -s secret.key -p public.key ----- - -TIP: Store the +secret.key+ file in a *secure and reliable* location, you'll - need it to sign package repositories in the future. - -=== 3) Add public key to the repository - -Obtain the fingerprint of your public key with the +usign -F+ command and use -it as filename for storing the pubkey in the +keyring.git+ repository: - ----- -$ ./usign -F -p public.key -72a57f2191b211e0 ----- - -TIP: Add the key to Git, using the fingerprint as filename: - ----- -$ cd keyring/usign/ -$ cp /some/where/public.key 72a57f2191b211e0 -$ git add 72a57f2191b211e0 -$ git commit -sm "Add my public usign key" -$ git push origin master ----- diff --git a/pages/menu.inc b/pages/menu.inc deleted file mode 100644 index 172625b..0000000 --- a/pages/menu.inc +++ /dev/null @@ -1,9 +0,0 @@ -[role="menu"] -. pass:attributes[Home] -. pass:attributes[Communication] -. pass:attributes[Rules] -. pass:attributes[Development] -. pass:attributes[Todo] -. pass:attributes[Downloads] -. pass:attributes[Documentation] -. pass:attributes[About] diff --git a/pages/rules.txt b/pages/rules.txt deleted file mode 100644 index 25d5a83..0000000 --- a/pages/rules.txt +++ /dev/null @@ -1,53 +0,0 @@ -Project Rules -============= - -include::menu.inc[] - -== Current Rules - -. The only role distinction within the _LEDE_ project is between committers - and non-committers, there is no core developer group or other specially - privileged members. -. All committers have the right to vote and are invited to liberally exercise - this voting right in order to keep a broad consensus on project matters. -. Project matters, overall development directions etc. are decided by simple - majority votes. Votes may be held in different ways like simple yes/no - decisions, majority decisions among multiple proposed choices etc. -. Committers being unreachable for three months in a row shall get their - commit and voting rights revoked in order to retain the ability to do - majority votes among the remaining active committers. -. There shall be only full commit rights in any case, no partial access or - otherwise restricted access to the repositories. -. Frequent contributors may become committers after a simple majority - agreement among existing committers. Project members are free to suggest - suitable people. -. Any votes and decisions made will be made public on the project websites. -. Project infrastructure should be outsourced FOSS community operated - services whenever possible in order to allow project members to focus on - actual development efforts. -. Any infrastructure that cannot be outsourced and/or is operated by the - project itself shall be administrable by at least three different people - to reduce the likelyhood of the project getting locked out due to operators - being unreachable. Responsible operators for the various services shall be - documented publicly. -. The project will not offer email accounts under its project domain for - privacy and equality reasons. -. Changes to these rules require a two third majority among the committers - holding voting rights and shall be documented. -. Be nice to eachother. - -=== Changes to these rules === - -==== Mon, 10 May 2016 -Add the rule "Be nice to eachother" -Agreed in the meeting 9 May 2016 - -==== Tue, 5 Apr 2016 -Changed wording of the rules and removed typos. Extended infrastructure -rule to emphasize the FOSS character of used hosting services, added -requirement of documented responsibilities. -http://meetings.lede-project.org/lede-adm/2016/lede-adm.2016-04-05-12.59.html[Agreed upon] -by 6 of 6 attending and 6 of 8 total people. - -==== Thu, 24 Mar 2016 -Initial draft, http://meetings.lede-project.org/lede-adm/2016/lede-adm.2016-03-30-11.05.html[agreed upon by 6 of 6 attending people]. diff --git a/pages/signing.txt b/pages/signing.txt deleted file mode 100644 index 006e931..0000000 --- a/pages/signing.txt +++ /dev/null @@ -1,128 +0,0 @@ -Release Signing -=============== - -include::menu.inc[] - -== Signing Approach - -LEDE uses both https://www.gnupg.org/[GnuPG] and _usign_, a derivate of the -OpenBSD http://www.openbsd.org/papers/bsdcan-signify.html[_signify_] utilitiy. - -The _OPKG_ package manager uses _usign_ Ed25519 signatures to verify repository -metadata when installing packages while release image files are usually signed -by one or more developers with detached GPG signatures to allow users to verify -the integrity of installation files. - -Our _usign_ signature files carry the extension +.sig+ while the detached -GPG signatures end with +.gpg+. - -Note that not every file is signed individually but that we're signing the -+md5sums+ and +sha256sums+ or - for repositories - the +Packages+ files to -establish a chain of trust: The SHA256 checksum will verify the integrity of the -actual file while the signature will verify the integrity of the file containing -the checksums. - -=== Verify download integrity - -In order to verify the integrity of a firmware download you need to do the -following steps: - -. Download the +sha256sum+ and +sha256sum.gpg+ files -. Check the signature with +gpg --with-fingerprint --verify sha256sum.gpg - sha256sum+, ensure that the GnuPG command reports a good signature and that - the fingerprint matches the ones listed on our fingerprints (TODO:link) page. -. Download the firmware image and calculate its hash using one of the - +sha256sum+ or +openssl sha256+ commands. -. Verify that the calculated checksum matches the one listed in the +sha256sums+ - file. - -You can use the example script below to verify the integrity of image downloads, -call it as +./script.sh https://downloads.lede-project.org/path/to/image.bin+ - ----- -#!/bin/bash - -[ -n "$1" ] || { - echo "Usage: $0 " >&2 - exit 1 -} - -finish() { - echo "Cleaning up." - rm -r "/tmp/verify.$$" - exit $1 -} - -trap "finish 7" INT TERM - -destdir="$(pwd)" -image_url="$1" -image_file="${image_url##*/}" -sha256_url="${image_url%/*}/sha256sums" -gpgsig_url="${image_url%/*}/sha256sums.gpg" - -mkdir -p "/tmp/verify.$$" -cd "/tmp/verify.$$" - -echo "1) Downloading image file" -echo "=========================" -wget -O "$image_file" "$image_url" || { - echo "Failed to download image file!" >&2 - finish 1 -} - -echo "2) Downloading checksum file" -echo "============================" -wget -O "sha256sums" "$sha256_url" || { - echo "Failed to download checksum file!" >&2 - finish 2 -} - -echo "3) Downloading the GPG signature" -echo "================================" -wget -O "sha256sums.gpg" "$gpgsig_url" || { - echo "Failed to download GPG signature!" >&2 - finish 3 -} - -echo "4) Verifying GPG signature" -echo "==========================" -gpg --with-fingerprint --verify "sha256sums.gpg" "sha256sums" || { - echo "Failed to verify checksum file with GPG signature!" >&2 - finish 4 -} - -echo "" -echo "5) Verifying SHA256 checksum" -echo "============================" -remote_csum="$(grep -F "SHA256($image_file)=" "sha256sums")" -local_csum="$(openssl sha256 "$image_file")" -[ "$remote_csum" = "$local_csum" ] || { - echo "Checksums do not match!" >&2 - echo "REMOTE: $remote_csum" >&2 - echo "LOCAL: $local_csum" >&2 - finish 5 -} - -cp "$image_file" "$destdir/$image_file" || { - echo "Failed to write '$destdir/$image_file'" >&2 - finish 6 -} - -echo "" -echo "Verficiation done!" -echo "==================" -echo "Firmware image placed in '$dest_dir/$image_file'." - -finish 0 ----- - - -=== Developer information - -Developers participating in the LEDE project need to provide both _GnuPG_ and -_usign_ public keys which are stored in the central -https://git.lede-project.org/?p=keyring.git[keyring.git] repository. - -Refer to the link:/keygen.html[key generation howto] page for instruction on how to -generate suitable signing keys. diff --git a/pages/todo.txt b/pages/todo.txt deleted file mode 100644 index c90c3b5..0000000 --- a/pages/todo.txt +++ /dev/null @@ -1,49 +0,0 @@ -Project ToDos -============= - -include::menu.inc[] - -== TODO List - -This page lists the current project wide todos. Items listed in random order without any prioritisation. - -=== Project Reboot - -. Announce publicly -. Invite new developers -. Write letter of invite to (mesh) communities using the code base -. Ask communities to endorse _LEDE_ -. Announce feature freeze and start stabilising trunk -. Prepare _LEDE_ #1 release - -=== Infrastructure - -. Provide a master for the download mirroring infrastructure -. Find mirroring capacity - we liberally distribute rsync keys if you have bandwidth and storage available on trusted infrastructure contact us -. Setup an issue tracker -. What shall we do about wiki and forum ? -. Find a Web Person to do some CSS magic - -=== Code base - -. Review recent IPV6 changes -. Review and fix procd, netfid, firewall issues/quirks -. Bump all kernels to v4.4 -. Review PPPoE support -. Convert ar71xx to devicetree -. Document core services (procd, netifd, ...) -. Build new UCI docs -. Define rules for board support status Green, Orange, Red and start testing all supported boards -. integrate keyring support - -=== Releases - -. Define the scope of the first release -. Define pre-release testing rules/guidelines -. Decide on new naming scheme - YY.MM + animal names have been proposed as an naming option - -=== Buildbot Setup - -. Rework buildbot setup to allow running more than one build in the same tree -. Rework buildbot setup to allow building release on the same setup - diff --git a/rules.txt b/rules.txt new file mode 100644 index 0000000..25d5a83 --- /dev/null +++ b/rules.txt @@ -0,0 +1,53 @@ +Project Rules +============= + +include::menu.inc[] + +== Current Rules + +. The only role distinction within the _LEDE_ project is between committers + and non-committers, there is no core developer group or other specially + privileged members. +. All committers have the right to vote and are invited to liberally exercise + this voting right in order to keep a broad consensus on project matters. +. Project matters, overall development directions etc. are decided by simple + majority votes. Votes may be held in different ways like simple yes/no + decisions, majority decisions among multiple proposed choices etc. +. Committers being unreachable for three months in a row shall get their + commit and voting rights revoked in order to retain the ability to do + majority votes among the remaining active committers. +. There shall be only full commit rights in any case, no partial access or + otherwise restricted access to the repositories. +. Frequent contributors may become committers after a simple majority + agreement among existing committers. Project members are free to suggest + suitable people. +. Any votes and decisions made will be made public on the project websites. +. Project infrastructure should be outsourced FOSS community operated + services whenever possible in order to allow project members to focus on + actual development efforts. +. Any infrastructure that cannot be outsourced and/or is operated by the + project itself shall be administrable by at least three different people + to reduce the likelyhood of the project getting locked out due to operators + being unreachable. Responsible operators for the various services shall be + documented publicly. +. The project will not offer email accounts under its project domain for + privacy and equality reasons. +. Changes to these rules require a two third majority among the committers + holding voting rights and shall be documented. +. Be nice to eachother. + +=== Changes to these rules === + +==== Mon, 10 May 2016 +Add the rule "Be nice to eachother" +Agreed in the meeting 9 May 2016 + +==== Tue, 5 Apr 2016 +Changed wording of the rules and removed typos. Extended infrastructure +rule to emphasize the FOSS character of used hosting services, added +requirement of documented responsibilities. +http://meetings.lede-project.org/lede-adm/2016/lede-adm.2016-04-05-12.59.html[Agreed upon] +by 6 of 6 attending and 6 of 8 total people. + +==== Thu, 24 Mar 2016 +Initial draft, http://meetings.lede-project.org/lede-adm/2016/lede-adm.2016-03-30-11.05.html[agreed upon by 6 of 6 attending people]. diff --git a/signing.txt b/signing.txt new file mode 100644 index 0000000..006e931 --- /dev/null +++ b/signing.txt @@ -0,0 +1,128 @@ +Release Signing +=============== + +include::menu.inc[] + +== Signing Approach + +LEDE uses both https://www.gnupg.org/[GnuPG] and _usign_, a derivate of the +OpenBSD http://www.openbsd.org/papers/bsdcan-signify.html[_signify_] utilitiy. + +The _OPKG_ package manager uses _usign_ Ed25519 signatures to verify repository +metadata when installing packages while release image files are usually signed +by one or more developers with detached GPG signatures to allow users to verify +the integrity of installation files. + +Our _usign_ signature files carry the extension +.sig+ while the detached +GPG signatures end with +.gpg+. + +Note that not every file is signed individually but that we're signing the ++md5sums+ and +sha256sums+ or - for repositories - the +Packages+ files to +establish a chain of trust: The SHA256 checksum will verify the integrity of the +actual file while the signature will verify the integrity of the file containing +the checksums. + +=== Verify download integrity + +In order to verify the integrity of a firmware download you need to do the +following steps: + +. Download the +sha256sum+ and +sha256sum.gpg+ files +. Check the signature with +gpg --with-fingerprint --verify sha256sum.gpg + sha256sum+, ensure that the GnuPG command reports a good signature and that + the fingerprint matches the ones listed on our fingerprints (TODO:link) page. +. Download the firmware image and calculate its hash using one of the + +sha256sum+ or +openssl sha256+ commands. +. Verify that the calculated checksum matches the one listed in the +sha256sums+ + file. + +You can use the example script below to verify the integrity of image downloads, +call it as +./script.sh https://downloads.lede-project.org/path/to/image.bin+ + +---- +#!/bin/bash + +[ -n "$1" ] || { + echo "Usage: $0 " >&2 + exit 1 +} + +finish() { + echo "Cleaning up." + rm -r "/tmp/verify.$$" + exit $1 +} + +trap "finish 7" INT TERM + +destdir="$(pwd)" +image_url="$1" +image_file="${image_url##*/}" +sha256_url="${image_url%/*}/sha256sums" +gpgsig_url="${image_url%/*}/sha256sums.gpg" + +mkdir -p "/tmp/verify.$$" +cd "/tmp/verify.$$" + +echo "1) Downloading image file" +echo "=========================" +wget -O "$image_file" "$image_url" || { + echo "Failed to download image file!" >&2 + finish 1 +} + +echo "2) Downloading checksum file" +echo "============================" +wget -O "sha256sums" "$sha256_url" || { + echo "Failed to download checksum file!" >&2 + finish 2 +} + +echo "3) Downloading the GPG signature" +echo "================================" +wget -O "sha256sums.gpg" "$gpgsig_url" || { + echo "Failed to download GPG signature!" >&2 + finish 3 +} + +echo "4) Verifying GPG signature" +echo "==========================" +gpg --with-fingerprint --verify "sha256sums.gpg" "sha256sums" || { + echo "Failed to verify checksum file with GPG signature!" >&2 + finish 4 +} + +echo "" +echo "5) Verifying SHA256 checksum" +echo "============================" +remote_csum="$(grep -F "SHA256($image_file)=" "sha256sums")" +local_csum="$(openssl sha256 "$image_file")" +[ "$remote_csum" = "$local_csum" ] || { + echo "Checksums do not match!" >&2 + echo "REMOTE: $remote_csum" >&2 + echo "LOCAL: $local_csum" >&2 + finish 5 +} + +cp "$image_file" "$destdir/$image_file" || { + echo "Failed to write '$destdir/$image_file'" >&2 + finish 6 +} + +echo "" +echo "Verficiation done!" +echo "==================" +echo "Firmware image placed in '$dest_dir/$image_file'." + +finish 0 +---- + + +=== Developer information + +Developers participating in the LEDE project need to provide both _GnuPG_ and +_usign_ public keys which are stored in the central +https://git.lede-project.org/?p=keyring.git[keyring.git] repository. + +Refer to the link:/keygen.html[key generation howto] page for instruction on how to +generate suitable signing keys. diff --git a/todo.txt b/todo.txt new file mode 100644 index 0000000..c90c3b5 --- /dev/null +++ b/todo.txt @@ -0,0 +1,49 @@ +Project ToDos +============= + +include::menu.inc[] + +== TODO List + +This page lists the current project wide todos. Items listed in random order without any prioritisation. + +=== Project Reboot + +. Announce publicly +. Invite new developers +. Write letter of invite to (mesh) communities using the code base +. Ask communities to endorse _LEDE_ +. Announce feature freeze and start stabilising trunk +. Prepare _LEDE_ #1 release + +=== Infrastructure + +. Provide a master for the download mirroring infrastructure +. Find mirroring capacity - we liberally distribute rsync keys if you have bandwidth and storage available on trusted infrastructure contact us +. Setup an issue tracker +. What shall we do about wiki and forum ? +. Find a Web Person to do some CSS magic + +=== Code base + +. Review recent IPV6 changes +. Review and fix procd, netfid, firewall issues/quirks +. Bump all kernels to v4.4 +. Review PPPoE support +. Convert ar71xx to devicetree +. Document core services (procd, netifd, ...) +. Build new UCI docs +. Define rules for board support status Green, Orange, Red and start testing all supported boards +. integrate keyring support + +=== Releases + +. Define the scope of the first release +. Define pre-release testing rules/guidelines +. Decide on new naming scheme - YY.MM + animal names have been proposed as an naming option + +=== Buildbot Setup + +. Rework buildbot setup to allow running more than one build in the same tree +. Rework buildbot setup to allow building release on the same setup +