--- /dev/null
+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
+|====
--- /dev/null
+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]
--- /dev/null
+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.
--- /dev/null
+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/
--- /dev/null
+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"]
--- /dev/null
+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
+ <n> = key expires in n days
+ <n>w = key expires in n weeks
+ <n>m = key expires in n months
+ <n>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) <heinrichh@duesseldorf.de>"
+
+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) <jo@mein.io>"
+
+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) <jo@mein.io>
+
+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) <jo@mein.io>
+----
+
+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) <jo@mein.io>"
+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
+ <n> = key expires in n days
+ <n>w = key expires in n weeks
+ <n>m = key expires in n months
+ <n>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) <jo@mein.io>
+----
+
+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)
+<jo@mein.io>" 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) <jo@mein.io>
+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 <command> <options>
+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 <comment>: add comment to keys
+ -m <file>: message file
+ -p <file>: public key file (verify/fingerprint only)
+ -P <path>: public key directory (verify only)
+ -q: quiet (do not print verification result, use return code only)
+ -s <file>: secret key file (sign/fingerprint only)
+ -x <file>: signature file (defaults to <message file>.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
+----
--- /dev/null
+[role="menu"]
+. pass:attributes[<a href="index.html" class="{docname@index:active}">Home</a>]
+. pass:attributes[<a href="communication.html" class="{docname@communication:active}">Communication</a>]
+. pass:attributes[<a href="rules.html" class="{docname@rules:active}">Rules</a>]
+. pass:attributes[<a href="development.html" class="{docname@development:active}">Development</a>]
+. pass:attributes[<a href="todo.html" class="{docname@todo:active}">Todo</a>]
+. pass:attributes[<a href="downloads.html" class="{docname@downloads:active}">Downloads</a>]
+. pass:attributes[<a href="docs/index.html">Documentation</a>]
+. pass:attributes[<a href="about.html" class="{docname@about:active}">About</a>]
+++ /dev/null
-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
-|====
+++ /dev/null
-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]
+++ /dev/null
-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.
+++ /dev/null
-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/
+++ /dev/null
-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"]
+++ /dev/null
-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
- <n> = key expires in n days
- <n>w = key expires in n weeks
- <n>m = key expires in n months
- <n>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) <heinrichh@duesseldorf.de>"
-
-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) <jo@mein.io>"
-
-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) <jo@mein.io>
-
-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) <jo@mein.io>
-----
-
-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) <jo@mein.io>"
-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
- <n> = key expires in n days
- <n>w = key expires in n weeks
- <n>m = key expires in n months
- <n>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) <jo@mein.io>
-----
-
-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)
-<jo@mein.io>" 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) <jo@mein.io>
-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 <command> <options>
-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 <comment>: add comment to keys
- -m <file>: message file
- -p <file>: public key file (verify/fingerprint only)
- -P <path>: public key directory (verify only)
- -q: quiet (do not print verification result, use return code only)
- -s <file>: secret key file (sign/fingerprint only)
- -x <file>: signature file (defaults to <message file>.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
-----
+++ /dev/null
-[role="menu"]
-. pass:attributes[<a href="index.html" class="{docname@index:active}">Home</a>]
-. pass:attributes[<a href="communication.html" class="{docname@communication:active}">Communication</a>]
-. pass:attributes[<a href="rules.html" class="{docname@rules:active}">Rules</a>]
-. pass:attributes[<a href="development.html" class="{docname@development:active}">Development</a>]
-. pass:attributes[<a href="todo.html" class="{docname@todo:active}">Todo</a>]
-. pass:attributes[<a href="downloads.html" class="{docname@downloads:active}">Downloads</a>]
-. pass:attributes[<a href="docs/index.html">Documentation</a>]
-. pass:attributes[<a href="about.html" class="{docname@about:active}">About</a>]
+++ /dev/null
-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].
+++ /dev/null
-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 <url>" >&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.
+++ /dev/null
-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
-
--- /dev/null
+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].
--- /dev/null
+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 <url>" >&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.
--- /dev/null
+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
+
projects / web.git / commitdiff