tor-dev

tor-dev@lists.torproject.org

3581 discussions

Request for comment: AEZ for relay cryptography
by Nick Mathewson 21 Oct '15

21 Oct '15

[This is a draft proposal; I'm not giving it a number yet. I'm hoping it'll receive some good advice.] Filename: xxx-aez-relay.txt Title: AEZ for relay cryptography Author: Nick Mathewson Created: 13 Oct 2015 Status: Draft 1. Summary and preliminaries This proposal describes an improved algorithm for circuit encryption, based on the wide-block SPRP AEZ. I also describe the attendant bookkeeping, including CREATE cells, and several variants of the proposal. For more information about AEZ, see http://web.cs.ucdavis.edu/~rogaway/aez/ For motivations, see proposal 202. 2. Specifications 2.1. New CREATE cell types. We add a new CREATE cell type that behaves as an ntor cell but which specifies that the circuit will be created to use this mode of encryption. [TODO: Can/should we make this unobservable?] The ntor handshake is performed as usual, but a different PROTOID is used: "ntor-curve25519-sha256-aez-1" To derive keys under this handshake, we still use HKDF_SHA256, but we produce 96 bytes of output: struct hkdf_output { u8 key_forward[48]; u8 key_backward[48]; }; These two fields are constant for the lifetime of the circuit. (But see section 4.3 below.) (Also see 4.1 for a variant that uses less storage key material.) 2.2. New relay cell payload We specify the following relay cell payload format, to be used when the exit node circuit hop was created with the CREATE format in 2.1 above: struct relay_cell_payload { u32 zero_1; u16 zero_2; u16 stream_id; u16 length IN [0..498]; u8 command; u8 data[498]; // payload_len - 11 }; Note that the payload length is unchanged. The fields are now rearranged to be aligned. The 'recognized' and 'length' fields are replaced with zero_1, zero_2, and the high 7 bits of length, for a minimum of 55 bits of unambigious verification. (Additional verification can be done by checking the other fields for correctness; AEZ users can exploit plaintext redundancy for additional cryptographic checking.) When encrypting a cell for a hop that was created using one of these circuits, clients and relays encrypt them using the AEZ algorithm with the following parameters: Key = Kf for forward cells, Kb for backward cells. # In theory, we are allowed to use a single key here, but I'm # tau = 0 # We want no per-hop ciphertext expansion. Instead we use # redundancy in the plaintext to authenticate the data. Nonce = struct { u64 cell_number; u8 is_forward; u8 is_early; } # The cell number is the number of relay cells that have # traveled in this direction on this circuit before this cell. # ie, it's zero for the first cell, two for the second, etc. # # is_forward is 1 for outbound cells, 0 for inbound cells. # is_early is 1 for cells packaged as RELAY_EARLY, 0 for # cells packaged as RELAY. # # Technically these two values would be more at home in AD # than in Nonce; but AEZ doesn't actually distinguish N and AD # internally. AD = [ The last 32 bytes of the previous cell's plaintext, if this is not the first cell sent in this direction on this circuit ] # Using this as additional data guarantees that any corrupt # ciphertext received will corrupt the plaintext, which will # corrupt all future plaintexts. Using the last 32 bytes of the # ciphertext would not have the same property. This instantiates a wide-block cipher, tweaked based on the cell index and direction. It authenticates part of the previous cell's plaintext, thereby ensuring that if the previous cell was corrupted, this cell will be unrecoverable. 3. Design considerations 3.1. Wide-block pros and cons? See proposal 202, section 4. 3.2. Given wide-block, why AEZ? It's a reasonably fast probably secure wide-block cipher. In particular, it's performance-competitive with AES_CTR. (How fast is it? To encrypt a 509-byte relay cell with a 16 byte nonce and 32 bytes of additional data, AEZ only uses 360 aes rounds. This is the same number of aes rounds as we'd need to CTR encrypt a 512-byte cell with 11.25 rounds per block. AES128 uses 10 rounds per block; AES256 uses 14 rounds per block. We could chop out 4 of the AES rounds by optimizing the code for the tau=0 case, or with AD shenenegans, but that's probably unwise. Additionally, we would no longer need to maintain a running SHA-1 of cells.) It seems secure-ish too. Several cryptographers I know seem to think it's likely secure enough, and almost surely at least as good as AES. [There are many other competing wide-block SPRP constructions if you like. Many require blocks be an integer number of blocks, or aren't tweakable. Some are slow. Do you know a good one?] 3.3. Why _not_ AEZ? There are also some reasons to consider avoiding AEZ, even if we do decide to use a wide-block cipher. FIRST it is complicated to implement. As the specification says, "The easiness claim for AEZ is with respect to ease and versatility of use, not implementation." SECOND, it's still more complicated to implement well (fast, side-channel-free) on systems without AES acceleration. We'll need to pull the round functions out of fast assembly AES, which is everybody's favorite hobby. THIRD, it's really horrible to try to do it in hardware. FOURTH, it is comparatively new. Although several cryptographers like it, and it is closely related to a system with a security proof, you never know. FIFTH, something better may come along. 4. Alternative designs 4.1. Only one key We already use different nonces for the forward and reverse direction; according to the AEZ design, this is sufficient to give security, even if K_b and K_f are the same. We could generate and store only half as much key material by using only a single key per circuit. 4.2. Authenticating things differently Adding only _a part of the plaintext_ of the previous cell seems a little screwy: that's usually easy information to predict. I believe this is secure, however, since the only purpose here is to ensure that _if_ the previous cell was corrupted, subsequent cells will be corrupted too. We could authenticate more stuff, however. We could, for example, authenticate the _entire_ previous ciphertext cell. Or we could authenticate the last 8 bytes of ciphertext and the last 24 bytes of plaintext. (Another thing we might dislike about the current proposal is that it appears to requires us to remember 32 bytes of plaintext until we get another cell. But that part is fixable: note that in the structure of AEZ, the AD is processed in the AEZ-hash() function, and then no longer used. We can compute the AEZ-hash() to be used for the next cell after each cell is en/de crypted.) 4.3. A forward-secure variant. We might want the property that after every cell, we can forget some secret that would enable us to decrypt that cell if we saw it again. One way to do this, at a little extra expense, is to keep a 16 or 32 byte 'chaining' value that changes after each cell. The initial chaining value in each direction would be another output of the HKDF. We could use it as an extra AD for the AEZ encryption. To update the chaining value, we need a one-way function. One option would be your-favorite-hash-function; blake2b isn't _that_ bad, right? We could also try to XOR it with a function of some hidden value from AEZ: E(S,-1,?) is promising, but it would require that we get our hands inside of our AEZ implementation. Also it would require a real cryptographer to come up with it. :) A more severe option is to update the entire key after each cell. This would conflict with 4.1 above, and cost us a bit more. A positively silly option would be to reserve the last X bytes of each relay cell's plaintext for random bytes, if they are not used for payload. This would help forward secrecy a little, in a really doofy way. Any other ideas? 4.4. SHA256 is stupid We could update the ntor definition used in this to use blake2b as its tweakable hash and for its KDF as well. (This would be faster _and_ more secure, not only because blake2b is lots faster than SHA256, but also because we could use the personalization and salt and key features of blake2b to avoid HMAC.) Or there's sha3 I guess if you want to do that.

5 4

Effect of padding on end to end correlation false positive rate
by s7r 20 Oct '15

20 Oct '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello, I have an idea which I want to put into a proposal, but need a clarification first so I won't be working on something which doesn't make a big difference. I am describing something like a Sybil attack where the adversary runs relays, gets lucky and is selected in a certain position of a certain rendezvous circuit and can do an end to end correlation of the traffic (both ends). This is different from one end correlation or website fingerprinting attack. For this scenario: HS -> Guard -> Middle1 -> Middle2 -> RDV -> MiddleC -> GuardC -> Client If the client is the attacker, and Middle1 is an evil relay colluding with him, and it was selected 2nd hop in a rendezvous circuit that connects the HS with the attacker (rendezvous is not colluding), he can learn the guard of the hidden service. The client (attacker) can send traffic over that circuit until he gathers enough data to make a fair assumption about where the traffic is coming from (identify the guard of that HS). I am not sure if there will even be a nonzero false positive rate in this context. Confirmation needed for these assumptions, this is what I think after reading: [0],[1]. Does this change with padding? If yes, how? For the same scenario described above, if padding is used, will the attacker have to own the entire path to the guard (Middle1 and Middle2 in the same circuit, since the rest of the path is under his control to select anyway), in order to make a reasonable guess on which might be the guard he is interested in? Or can he make the difference between the real traffic and the padding / dummy traffic and have the same results as with no padding? [0]: https://blog.torproject.org/blog/one-cell-enough [1]: https://blog.torproject.org/blog/traffic-correlation-using-netflows -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBCAAGBQJWIU5yAAoJEIN/pSyBJlsRlj4H+wcAc958SazmoXgYTtJisK5R dgcWZILgnYTYg17ub8Y3Hsgh0YjJyEgwgXV/r6ftNNir8kMSn3t+KMFAt9OpVhOJ 4W0f3E/X18viJNn3Pcb3FDc41sXxpwMVdUd337wGzqaNb8wsCARspmkDv9gdsLje GTTrz2MUa6lWyZHEuJMp02W2pkPVr48UnOsd0S0lyiDM3uxAAQyEtS9XwQyd+hBE KgLG7DHgwOnNzpBeQYJ5KlTzWi6j/NGxXcnHWcuWkq32ZG/gQsw6I43BNV9DMs6r 3UJbrdHsYJKDq8I16Ir0fblaOjsxmU7cEZZioOVngmw8wG6KevGI7fYKsEcqAhk= =CJly -----END PGP SIGNATURE-----

2 1

ResearchEthics
by grarpamp 19 Oct '15

19 Oct '15

https://trac.torproject.org/projects/tor/wiki/doc/ResearchEthics Any number of problems and obstacles to legitimate research areas exist with this... " Examples of unacceptable research activity It is not acceptable to run an HSDir, harvest onion addresses, and do a Web crawl of those onion services. Don't set up exit relays to sniff, or tamper with exit traffic. " Assuming such bans, how is one supposed to legitimately research and report on the real makeup of onion or exit space? These are significant unanswered questions regarding tor use. Concentrate not on bans, which will be ignored by both legit and illegit researchers anyways, but on proper design for data handling and minimization, particularly being sensitive to the tor users and operators involved lest that data become compromised at any stage before final anonymization and wiping.

5 7

Time-to-first-byte on trac.torproject.org
by Virgil Griffith 19 Oct '15

19 Oct '15

I started using Trac a bit more and the slowness is a little unpleasant. Here are some stats: http://www.webpagetest.org/result/151019_RW_387/ The time-to-first-byte is *painful* on both the first load as well as reload. Are there some ways we could improve this? If it's sever-power I'm willing to contribute to a fund for it, but my first thought is that more internal caching needs to be turned on within Trac. Common queries like the frontpage shouldn't be this difficult. But they are inherently this difficult, then we should at least spread it out among multiple machines. -V

1 0

Another Virtual Network Environment needs your I/O
by Rob van der Hoeven 18 Oct '15

18 Oct '15

Hi folks, During this hot summer I did some cool programming which resulted in... Another Virtual Network Environment (avne) AVNE is a small Linux program that runs other programs inside a virtual network environment. All network traffic from this environment is intercepted and forwarded to the Tor network. Interception is transparent and is guaranteed to be 100% effective. To forward network traffic you can simply type avne followed by a program name. Examples: avne bash avne ip link avne iceweasel -P avne -no-remote avne chromium --disable-cache avne wget https://blog.torproject.org/ Because the network interception takes place at the IP-level, no special Tor configuration is needed. In theory all TCP-clients should now be able to use the Tor network. AVNE is currently in the alpha phase of development. It works quite well, but for the for the first beta version I need input from this community. First of all I want to know if there are programs that do not work with avne. I tested with firefox, chromium, wget etc. and encountered no problems. The second question I have is: are there programs / protocols which should be blocked by avne? For example: I think its a bad idea to support unencrypted POP3. Of course I am also interested in bug-reports and your ideas for improvement. On my blog I wrote an article about avne that explains the technologies it uses (User Space Networking and Lightweight virtualization), and also gives an overview of its implementation. You can find the article here: https://hoevenstein.nl/another-virtual-network-environment The source code can be downloaded at: https://hoevenstein.nl/downloads An on-line viewable version of the code is at: https://hoevenstein.nl/source-code-avne-c Hope you like the ideas and code. And of course, your feedback is much appreciated! Rob. https://hoevenstein.nl

2 5

Re: [tor-dev] Crux: Privacy-preserving statistics for Tor
by Vasilios Mavroudis 18 Oct '15

18 Oct '15

Hi, so you were right the databases were corrupt, but they shouldn't have been there in the first place. :-) I didn't want to include large files in the git repo (~120mb in total), so there is a generation script in the tools directory (now added). I added some instructions on the readme file too. Of course, this procedure is done only once. I tried it and it should work now, but let me know if there is still a problem. There is a plan to optimize the way the pre-computed values are used, and this could potentially shrink the size of the databases by a lot. Vasilis On 17 October 2015 at 15:56, str4d <str4d(a)i2pmail.org> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > str4d wrote: > > Vasilios Mavroudis wrote: > >> Hello, > > > >> I would like to introduce our project "Crux", which enables the > >> computation of privacy preserving statistics on sensitive data. > >> The project was developed at University College London (UCL) by > >> me, in close collaboration with George Danezis. > > > > This is fantastic work. Haven't read all of your thesis yet, but > > it looks similar to the stats collection system that we ran for a > > while inside I2P, but with the privacy protections that I wanted it > > to have. Well done! > > > > > >> "Crux" was designed with Tor hidden services in mind (in > >> accordance with this > >> <https://research.torproject.org/techreports/hidden-service-stats-201 > 5 > > > >> > - -04-28.pdf> > > > > > > Tor > >> Tech Report), but it can be applied on various kinds of data > >> (given an appropriate parser). > > > > Excellent. I want to use this in I2P :) > > > > > >> It supports three statistics (i.e. mean, median, variance) and > >> its threat model is compatible Tor's (see technical document > >> below). > > > > I will look into this, but I doubt there will be any > > insurmountable incompatibilities with I2P's threat model. > > > >> Currently, we don't have a parser specific for the data > >> collected by the Tor relays, but we plan to keep adding > >> functionality. > > > >> The source code can be found here: > >> https://github.com/mavroudisv/Crux The theoretical background, > >> threat model, security argument and technical details can be > >> found here: link <http://mavroudisv.eu/files/thesis.pdf> > > > > > >> Ideas, comments, feedback much appreciated! > > > > Firstly: needs more docs. I shouldn't have to read your entire > > thesis in order to figure out how to run it :P The README is a good > > start, but the command parameters need clarification/definitions, > > and it is not at all obvious how the relays work. An XLS file is > > also mentioned without explanation. > > I have now tried running the code, but the "unit test" run by > authority.py fails because bsbdb.btopen() returns an empty dict. I > don't know if this is because the table files are broken or because of > a local issue with my setup (I am using a virtualenv, but I get the > same empty dict when I try to open the tables manually outside the > virtualenv). I am not going to try and fix the latter on my own, > because bsddb is deprecated since Python 2.6, so you shouldn't really > be using it :) (But it must be something else, because I tried using > bsddb3 instead and that also returns an empty dict). > > str4d > > > > > Secondly, you could probably simplify configuration by managing > > hidden service connections yourself. I believe the Stem library can > > do this? I2P has a python library that can be used to listen on and > > connect to I2P Destinations, with a socket-like interface. > > > > It's not clear to me from your thesis whether you plan to merge > > the relay component into the Tor relay code (and have the Tor > > relays talk directly to the query processors), or have your relays > > running separately and interfacing with the Tor relays to fetch > > stats. This will potentially alter how it would be used with other > > networks. In I2P's case I'd imagine it would be easiest (in terms > > of usability by those setting up relays) to write an I2P plugin in > > Java that performs the relay role, but I wouldn't want to be > > duplicating a lot of logic that subsequently needs to be kept > > in-sync with upstream :) > > > > str4d > > > > > >> Vasilis > > > > > > > >> _______________________________________________ tor-dev mailing > >> list tor-dev(a)lists.torproject.org > >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > > > > _______________________________________________ tor-dev mailing > > list tor-dev(a)lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > > > -----BEGIN PGP SIGNATURE----- > > iQIcBAEBCgAGBQJWItIgAAoJEBO17ljAn7PglsQP/3tOrL9EZfYMb5fxxVI6/wJm > qDvA8RpbEJDhoMjOc9sLNyMVgvGGPxEdma8I/R8H37yIPOp2GJg82MoXfUk+AGFe > 5ZIIXwf2EzHH0RFLRI5xaQ4DW3Ru1yIzH+E3vhuGclL87YRKnAM0xkMQcueR5xo5 > /ETe9TI7oPCdETI4J6iFoM+Ob9qsRiEVeuT5HEFFKwQhBvl0NSpfMHV9ftuxQHuu > I2B9jomnBdzF9OXnSQrYXg3ho2rxX4hO1TZfQHg5DgHvkt8TQYQM3cwdGE7/rsqC > d4+kBW2RuAz68wq+fLPeeZ2U2ff2QqmDLqVyUJvpP5RqeUcv66J/iYm7md886tTc > palwVGodKiTJ6DBM0z1K97x6Sl1jJXEAkZQAr2yQ8jrC/BJqQRPu2vHeZILqbMEQ > UU3JLjIk/Jc2RGK6zitvj4kTrLdfACEQMYy3brQUawZhaM42QNQgb3LQq1bJXzUo > vISZckX/CVfF+R63oO085LYOO7oTLyY3EhA1PCXiV09Usl/To66Oh4AVYtz/lPLH > 6uoWR/ic5X9gFIXt1t+617+i/L/ILMfqkqN7GzoSbQ8QfyBJrjIikuj575M7AH3o > RuhRYHUTmaCRL+9niDFG/mSVGBxBqiSfW1eS5pGE3hIAcLQd0eFT/38HRdonkfLP > Ug5ihMFSKfKmCIljQ6mm > =jDmS > -----END PGP SIGNATURE----- >

1 0

Hello, I can't use Google Search Engine Service through Tor proxy.
by Li Xiaodong 18 Oct '15

18 Oct '15

*Hello, I can't use Google Search Engine Service through Tor proxy. Google asked me to enter a Verification Code. After I entered the Verification Code, Google asked me enter a new Verification Code. Could you please communicate this problem to Google Corporation? Could you please suggest to Google Corporation that it should allow Tor users to normally use Google Search Engine Service? Thank you very much for your help. I really appreciate it.*

2 1

Re: [tor-dev] Crux: Privacy-preserving statistics for Tor
by str4d 17 Oct '15

17 Oct '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 str4d wrote: > Vasilios Mavroudis wrote: >> Hello, > >> I would like to introduce our project "Crux", which enables the >> computation of privacy preserving statistics on sensitive data. >> The project was developed at University College London (UCL) by >> me, in close collaboration with George Danezis. > > This is fantastic work. Haven't read all of your thesis yet, but > it looks similar to the stats collection system that we ran for a > while inside I2P, but with the privacy protections that I wanted it > to have. Well done! > > >> "Crux" was designed with Tor hidden services in mind (in >> accordance with this >> <https://research.torproject.org/techreports/hidden-service-stats-201 5 > >> - -04-28.pdf> > > > Tor >> Tech Report), but it can be applied on various kinds of data >> (given an appropriate parser). > > Excellent. I want to use this in I2P :) > > >> It supports three statistics (i.e. mean, median, variance) and >> its threat model is compatible Tor's (see technical document >> below). > > I will look into this, but I doubt there will be any > insurmountable incompatibilities with I2P's threat model. > >> Currently, we don't have a parser specific for the data >> collected by the Tor relays, but we plan to keep adding >> functionality. > >> The source code can be found here: >> https://github.com/mavroudisv/Crux The theoretical background, >> threat model, security argument and technical details can be >> found here: link <http://mavroudisv.eu/files/thesis.pdf> > > >> Ideas, comments, feedback much appreciated! > > Firstly: needs more docs. I shouldn't have to read your entire > thesis in order to figure out how to run it :P The README is a good > start, but the command parameters need clarification/definitions, > and it is not at all obvious how the relays work. An XLS file is > also mentioned without explanation. I have now tried running the code, but the "unit test" run by authority.py fails because bsbdb.btopen() returns an empty dict. I don't know if this is because the table files are broken or because of a local issue with my setup (I am using a virtualenv, but I get the same empty dict when I try to open the tables manually outside the virtualenv). I am not going to try and fix the latter on my own, because bsddb is deprecated since Python 2.6, so you shouldn't really be using it :) (But it must be something else, because I tried using bsddb3 instead and that also returns an empty dict). str4d > > Secondly, you could probably simplify configuration by managing > hidden service connections yourself. I believe the Stem library can > do this? I2P has a python library that can be used to listen on and > connect to I2P Destinations, with a socket-like interface. > > It's not clear to me from your thesis whether you plan to merge > the relay component into the Tor relay code (and have the Tor > relays talk directly to the query processors), or have your relays > running separately and interfacing with the Tor relays to fetch > stats. This will potentially alter how it would be used with other > networks. In I2P's case I'd imagine it would be easiest (in terms > of usability by those setting up relays) to write an I2P plugin in > Java that performs the relay role, but I wouldn't want to be > duplicating a lot of logic that subsequently needs to be kept > in-sync with upstream :) > > str4d > > >> Vasilis > > > >> _______________________________________________ tor-dev mailing >> list tor-dev(a)lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > > _______________________________________________ tor-dev mailing > list tor-dev(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJWItIgAAoJEBO17ljAn7PglsQP/3tOrL9EZfYMb5fxxVI6/wJm qDvA8RpbEJDhoMjOc9sLNyMVgvGGPxEdma8I/R8H37yIPOp2GJg82MoXfUk+AGFe 5ZIIXwf2EzHH0RFLRI5xaQ4DW3Ru1yIzH+E3vhuGclL87YRKnAM0xkMQcueR5xo5 /ETe9TI7oPCdETI4J6iFoM+Ob9qsRiEVeuT5HEFFKwQhBvl0NSpfMHV9ftuxQHuu I2B9jomnBdzF9OXnSQrYXg3ho2rxX4hO1TZfQHg5DgHvkt8TQYQM3cwdGE7/rsqC d4+kBW2RuAz68wq+fLPeeZ2U2ff2QqmDLqVyUJvpP5RqeUcv66J/iYm7md886tTc palwVGodKiTJ6DBM0z1K97x6Sl1jJXEAkZQAr2yQ8jrC/BJqQRPu2vHeZILqbMEQ UU3JLjIk/Jc2RGK6zitvj4kTrLdfACEQMYy3brQUawZhaM42QNQgb3LQq1bJXzUo vISZckX/CVfF+R63oO085LYOO7oTLyY3EhA1PCXiV09Usl/To66Oh4AVYtz/lPLH 6uoWR/ic5X9gFIXt1t+617+i/L/ILMfqkqN7GzoSbQ8QfyBJrjIikuj575M7AH3o RuhRYHUTmaCRL+9niDFG/mSVGBxBqiSfW1eS5pGE3hIAcLQd0eFT/38HRdonkfLP Ug5ihMFSKfKmCIljQ6mm =jDmS -----END PGP SIGNATURE-----

1 0

Tor Environment Variables
by Dewayne Hicks 16 Oct '15

16 Oct '15

Hi, Is there a specific page (wiki/docs) that details all of the Tor environment variables for Linux? Ideally this would also map to TBB preferences access via about:config. The topic has been mentioned occasionally on the issue tracker [1] but the actual variables are spread out over a number of pages and it's not clear if the lists are complete. Thanks [1]: https://trac.torproject.org/projects/tor/ticket/13005

1 0

Trac priorities and severities
by David Goulet 15 Oct '15

15 Oct '15

Hello tor-dev! While 028 bug triaging, we realized that we *really* need priorities to not be a banana field deprive of useful meaning. If you are unaware or don't remember, the priority field in a trac ticket can be: blocker critical major normal minor trivial Those are "severities" *NOT* priorities. Now I propose the following: 1) I take those above and copy them to the already existing but empty severity field. They seem reasonable and we are used to them. 2) Rename all priorities to something more meaninful: blocker --> Immediate criticial --> Very High major --> High normal --> Medium minor --> Low trivial --> Very Low 3) World trac domination! This could get confusing for some tickets after that but at least we can transition towards using the Severity field from now on. Anyone object or think it's a bad bad idea? This is very little work for lots of benefits so I don't want to get into a massive reorg. or bike-shedding the naming convention. I would be open though to drop the "Very [High|Low]" field but that could make some tickets with less semantic. I'll let that sync for some days before doing anything. Let's not wait anymore and take back our Trac system! Freeeeeeeeeedom!!!!! Cheers! David

6 8

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev