User talk:Grazzolini

From ArchWiki
Latest comment: 5 January 2017 by Grazzolini in topic Edits to terminator

Configuration changes?

Nice work! I'm planning on converting my systems soon, and I'm particularly interested in what configuration changes need to be made. For example, /etc/default/grub, /etc/grub.d, /etc/mkinitcpio.conf (aside from adding the hooks). Will GRUB automagically detect that the boot disk is LUKS formatted, and Just Work™, or do I need to tell it to add cryptodisk.mod and related modules? EscapedNull (talk) 19:55, 11 March 2015 (UTC)Reply[reply]

I am writing, as of this moment, the crypttab configuration. The last part is grub configuration and reinstall. But, grub only needs GRUB_ENABLE_CRYPTODISK=y on /etc/default/grub. The catch is, that you need all your partitions mounted, including your ESP and new boot, and you need to use grub alternative install method mentioned. The grub part is the easiest one. Grazzolini (talk) 20:03, 11 March 2015 (UTC)Reply[reply]
Thanks for clarifying. I was unsure because I didn't see any changes to the GRUB files mentioned. The new section is very understandable, and easier than I expected. EscapedNull (talk) 10:47, 13 March 2015 (UTC)Reply[reply]
I have finished writing the article. Now I need suggestions and critics for it being able to integrate the main wiki. Grazzolini (talk) 20:40, 11 March 2015 (UTC)Reply[reply]
Alright, that's written in a comprehensive structure as a stand-alone page! To start I quickly summarize again the pointers we have for the content from the other talk, a little adjusted after reading what you wrote:
  1. GRUB#Root_encryption - a. the verbose about the CRYPTODISK parameter with link to the upstream doc, b. brief mention of partitioning alternatives for the boot partition - linking to the next for instructions, c. mention of the "double unlock"
  2. Dm-crypt/Drive_preparation#Partitioning - a. own subsection for Grub boot partition with alternative instructions for non-/dedicated /boot, b. one general example of how to convert an existing /boot parttion (User:Grazzolini#BIOS.2FMBR_2; no need for more than one example. I would choose the simple one, User:Grazzolini#UEFI.2FGPT_2 is too verbose in my view)
  3. Dm-crypt/Encrypting_a_non-root_file_system - theoretically this would be an alternate target to #partitioning (above) for more elaborate instructions about /boot alternatives. Personally I find it inappropriate as a target for content about /boot though.
  4. Dm-crypt/Encrypting_an_entire_system (a. addition of one new scenario; IMO best is the EFI/GPT setup with dedicated /boot. The scenario would crosslink anyway with the other sections, e.g. Dm-crypt/Drive_preparation#Partitioning, so the instructions contained in the scenario can be left out from the others. (A bit unfortunate you did not follow the secton structure we have for the scenarios for an example yet.)
  5. Dm-crypt/Specialties#Securing_the_unencrypted_boot_partition - a. content about your chkboot hook
Obviously new content be moved under its own subsections, where appropriate, of above targets. Once you have considered yourself which part could be moved where, you could add link targets to your article to point to. Easier for others to comment on then. That's it from me. --Indigo (talk) 21:21, 12 March 2015 (UTC)Reply[reply]
On critiquing, and I'm really just being pedantic here, the article could stand to be written in a slightly more formal tone. E.g. no first person pronouns, objective point of view, trivia and tangents placed in Note/Tip templates, etc. I'm quite happy with the actual content and the overall layout, however. EscapedNull (talk) 10:47, 13 March 2015 (UTC)Reply[reply]
Indigo, I'm already evaluating the changes you proposed. Also, Kynikos will take a look at this, in the weekend. EscapedNull, I was reading it again and you are right. It should be entirely in the third person. I am also taking a shot at shrinking some parts. I believe I can write on Partitioning how to resize, sort partitions. It is not only helpful in this case. With that the article will be way smaller. Grazzolini (talk) 16:58, 13 March 2015 (UTC)Reply[reply]
I agree with all the points Indigo has made (thank you). Since there is a lot of content to merge, currently structured in a standalone article (which we don't want), I suggest starting to create a new scenario in Dm-crypt/Encrypting_an_entire_system for the the EFI/GPT setup with dedicated /boot case, as Indigo said. Please try to use the same headings and style as the other scenarios in the page, and only add instructions for that specific case. Once that will be done, we'll see how to best move the remaining info in the other dm-crypt subpages, and properly crosslink everything.
About the conversions, I was thinking of the possibility to rename Dm-crypt/Encrypting_an_entire_system to "Dm-crypt/Installing_an_encrypted_system", and create a new "Dm-crypt/Encrypting_an_existing_system" subpage with some scenarios analogous to the current Dm-crypt/Encrypting_an_entire_system, what do you think?
At this stage I wouldn't waste time refining tone/grammar/style, we'll do that once everything is organized.
Kynikos (talk) 03:14, 15 March 2015 (UTC)Reply[reply]

Ok. I have analyzed both Indigo and Kynikos suggestions and I just want to be sure of what needs to be done:
On GRUB#Root_encryption, I will talk about CRYTODISK functionality and mention boot partition schemes.
Dm-crypt/Drive_preparation#Partitioning here I will mention the separate /boot or dedicated /boot and conversion example. I agree that User:Grazzolini#UEFI.2FGPT_2 is too verbose. And perhaps I can trim it a little bit. But I believe it is the most important example, since the User:Grazzolini#BIOS.2FMBR_2 is trivial. I know that initially, most users that will do this, will be seasoned users, that won't need detailed examples. But if this indeed become a default, more examples will be needed.
I also don't think that here Dm-crypt/Encrypting_a_non-root_file_system is the best place for talking about encrypted boot. It is a special case.
As for renaming scenarios, I will leave that to you guys. With GRUB cryptodisk functionality, I believe that it is a bit out of place talk about Dm-crypt/Encrypting_an_entire_system when it is not in fact the entire system that is encrypted. So a rename might be indeed the best solution. I will try to add the content all at once to the pages. I don't know if there is any other people moderating those pages.
Grazzolini (talk) 18:34, 17 March 2015 (UTC)Reply[reply]
Thanks for your considerations, Grazzolini. I hope the way proposed above also makes sense for you! Further, I'd like to pick up a point for my understanding: I am not sure from your answer whether we got the same understanding for what we call a "new scenario" in Dm-crypt/Encrypting a non-root file system (or (tbd) a renamed subpage): The idea here is to create a new additional scenario explaining how to install a new system with UEFI/GPT/GRUB CRYPTODISK /boot along the same structure of the other scenarios we have on the page (if you look at the scenarios again, you will note they are compared with pros/cons and then follow the same TOC structure each). The reason to create a new one is simply that this is the most popular subpage of dm-crypt and users will base their individual install on one of them. You do not mention the scenario itself in your answer, so I am not sure - what do you think about it? Or did you mean someone else (of us) should add the first draft of it?
I agree to Kynikos that on merging the content, it is useful to create the new scenario first. One reason to create it first is that after it has been added, it will be easier to crosslink (respectively add) content not covered in it yet to Dm-crypt/Drive_preparation#Partitioning in a general manner. The last point also applies to our discussion of "BIOS or UEFI conversion". As for your arguments to base the conversion example on User:Grazzolini#UEFI.2FGPT_2, that's fine with me. You put a lot of effort into providing accurate step-by-step instructions! One first suggestion for shortening it: according to my guess most LUKS users will have a separate /boot partition to convert already. Further, keeping /boot together with/on the ESP partition is mostly popular with Gummiboot users. Have a think whether this helps to shorten. --Indigo (talk) 23:05, 17 March 2015 (UTC)Reply[reply]
Yes, it made sense to me. Also, the new scenario idea is understood. I took note of your critique in the sense that I didn't wrote the article in the same structure as the other scenarios. It didn't occurred to me at the time I was writing to follow one of them. Sorry! It would be nice if one of you guys would write a draft of a new scenario. Specially because it will mean changing the name of a popular scenario. But I can do it also, no problems. You've guys have been great! It is not by chance that the archlinux wiki appears on the top of so many web search engines. As for thee UEFI/GPT conversion scenario, most of it talk about resizing and creation of partitions. The actual conversion is simple. I believe that this should go into Partitioning or GPT.
Grazzolini (talk) 00:00, 18 March 2015 (UTC)Reply[reply]
The mentioned conversion could be another example in GUID_Partition Table#Partitioning examples, yes. It'll get clearer once the first steps are done. I missed above that the GRUB#Root encryption part is the logical start anyway (before the scenario). I'd say feel free to start adding to the articles once you want to; we'll help as we go along. Alternatively, to plan further, you could add links per section to your current article to indicate where you want to put them and strike them once it's done. For the scenario, what could be a name for it? "Encrypted boot partition (GRUB)"? --Indigo (talk) 16:04, 19 March 2015 (UTC)Reply[reply]
As I am speaking I am writing on GUID_Partition Table#Partitioning examples the resize example, and the sorting example. I personally dislike the idea of writing a scenario in Dm-crypt/Encrypting_a_non-root_file_system. Specially, because in Dm-crypt#Common_scenarios it's stated that the Dm-crypt/Encrypting_a_non-root_file_system page is specifically for other devices not needed for booting a system. I will also write about CRYPTODISK functionality on GRUB#Root encryption, just pointing to the (very scarce) upstream documentation. But I won't link to any example, at least not now. Just so we can start moving things. I would like to have all this done soon. Thank you again.
Grazzolini (talk) 16:20, 19 March 2015 (UTC)Reply[reply]
Great. Yes, let's forget about Dm-crypt/Encrypting_a_non-root_file_system page, Dm-crypt/Drive_preparation#Boot_partition_.28GRUB.29 (or similar section there) is a more thankful target for the examples (of /boot as own partition and in the /). --Indigo (talk) 21:41, 19 March 2015 (UTC)Reply[reply]
I will try to write it there, as concisely as I can, and pointing to the already created info in the other articles. Hopefully we can finish it soon. Once again, thank you guys for all the help.
Grazzolini (talk) 15:41, 20 March 2015 (UTC)Reply[reply]
I just installed a new system (BIOS, CRYPTODISK=y, dedicated /boot with LUKS, separate /boot password, /boot in crypttab, btrfs root, no LVM (yet)) using your instructions, and I was pleasantly surprised with how painless it was. I might have spent two additional minutes setting up GRUB cryptodisk system in contrast to a cleartext /boot system. That being said, I almost feel like GRUB cryptodisk is too easy to warrant its own section on the scenarios page. Keep in mind this ignores LVM, UEFI, converting an existing system, etc. Instead of duplicating 90% of the process in another scenario, we might be better off placing notes like (e.g.) "If you want an encrypted /boot, use cryptsetup luksFormat instead of mkfs to format /dev/sdX2. See Dm-crypt/Specialties#GRUB_cryptodisk." I will ultimately leave it up to Indigo, Kynikos, and Grazzolini, however. EscapedNull (talk) 22:05, 21 March 2015 (UTC)Reply[reply]
Well, I thought similar, that's why I argued against a dedicated scenario when we started the talk. But I now think we should continue to add one, we just must make sure cryptodisk is not the only differentiating factor for the new scenario. We already agreed it using UEFI is a good other feature to illustrate in the new scenario along with it. Reading that you use btrfs for your root makes me remember an idea to add a configuration example for encrypted btrfs raid1. Maybe we could use the new cryptodisk scenario to fill the still missing RAID example. (features: EFI, non-raid but cryptodisk /boot, luks encrypted btrfs raid1 root). Your recent install experience would definetely be helpful! Would that be good or get too special for most users (who likely want to use standard LVM on LUKS instead) again? Thoughts? One point I am unsure about myself is whether we can get the two LUKS devices for the btrfs raid1 unlocked with the standard hooks; we would not want to add a modified encrypt hook for a standard scenario. You know that? Maybe: Does a btrfs root work with the systemd sd-encrypt hooks? (that would be another feature great to add on that subpage and make much sense with a cryptodisk /boot). --Indigo (talk) 12:40, 22 March 2015 (UTC)Reply[reply]
I agree that UEFI should be our main focus, because it is becoming standard, and the process is less obvious. I've only been ignoring it because I don't own any (U)EFI systems, and I have zero experience with them. As for using a multi-device Btrfs root, I successfully installed a four device raid1 encrypted root and remote unlocking on one of my machines, and there's no reason it would be incompatible with GRUB cryptodisk. However, I had to heavily modify the encryptssh hook to make it work. The cryptdevice parameter only takes one device. There might be some hope using the sd-encrypt hook, because it copies /etc/crypttab into the initrd, which might allow multiple devices to be unlocked, but I haven't tried it yet. See my comments on dropbear_initrd_encryptAUR.
I do feel that a multi-device Btrfs root could fit into the scenarios page without breaking the "same section names" rule, but I really don't know how popular it would be for most users. Aside from modifying the hook, I didn't think it was much harder than any of the standard setups, but then again I've been doing similar setups for a while now. I do intend to enable GRUB cryptodisk on that server soon, so I will be able to confirm that it is indeed compatible with a Btfs multi-device root in practice as soon as I do. I also don't think it's a good idea to write scenarios that rely on heavily modified hooks, so the Right Way™ here is to fix the encrypt hook to make it more flexible, and Grazzolini seems to have a solid plan for that, at least as far as dropbear_initrd_encryptAUR goes. That's off-topic, though, as compatibility with GRUB cryptodisk is the only thing relevant to this page, but please do feel free to start a discussion on my talk page or elsewhere if you're interested!
This is a bit of a rant, so sorry in advance for my demeanor. We've been going back and forth about scenarios and crosslinks and partitioning, etc. since User:Grazzolini finished the page over two weeks ago, and we've gotten nothing actually done in the default namespace. I'm more than happy to help out with writing/migrating, but can we please try to agree on what we're doing so I can get started and Grazzolini can get back to coding? From what I understand, Grazzolini has more things in the pipeline (encrypted chkboot in early userspace, decoupling dropbear from encryptssh, refactoring the net hook), and I'd like to see things move along. Are we writing a scenario or not? Are we branching the instruction flow of the existing scenarios using "Note: use cryptsetup luksFormat instead of mkfs, see GRUB cryptodisk" tags like I mentioned? Are we going to include "Converting an existing system" tutorials anywhere? Are we going to give GRUB cryptodisk a section under Dm-crypt/Specialties? Let's see if we can reach a consensus, rehash, and get to work. EscapedNull (talk) 21:15, 22 March 2015 (UTC)Reply[reply]
Have a look again, Grazzolini has started to merge content for (1) and (2) of above list before your replies. Yes, we want a scenario and it could be a todo for you to draft, if you want (see his comment above on it). Do you? I dumped the ideas above, because we all want it to be a meaningful new addition to the page. We have covered on where to merge the content, e.g. also where to put the "conversion" (please re-read above). Your suggestion for a general ""Note: use cryptsetup luksFormat..." (good idea) we can easily add to the general content above the scenarios, once the content is in place. --Indigo (talk) 22:28, 22 March 2015 (UTC)Reply[reply]
Sorry, I didn't see the changes to Dm-crypt/Encrypting_an_entire_system at first. I was using the wrong search terms apparently. So I guess it was just me getting nothing done in the default namespace. I wasn't sure if your overview of changes was still valid or not, since there were some new ideas introduced later in the discussion. I'm currently working on setting up a UEFI system under QEMU to test the scenario, and I'll write a draft as I go along. EscapedNull (talk) 00:40, 23 March 2015 (UTC)Reply[reply]

(Thread moved to left for readability --Indigo (talk) 12:49, 25 March 2015 (UTC))Reply[reply]

Nice to see things moving! Yes, I have a lot on my plate right now. But I will get this done this week. I want to improve mkinitcpio-chkcryptobootAUR, so it can detect boot partition bypass. After that I will go back to dropbear_initrd_encryptAUR. It will get a new name. But unfortunately, you can't use it with cryptodisk, because you won't get a completely remote unlock with it. If you come to think about, they are in the opposite directions in the sense of security. I use dropbear because I want the convenience of being able to unlock some servers of mine, from anywhere. I believe that GRUB cryptodisk is most useful in making your day to day machine (laptop or desktop) more secure. I plan to add even more checks to mkinitcpio-chkcryptobootAUR. It is working for me right now, but perhaps it can help others also. Also, I am not that worried about a new scenario or not. I will add it to the pages and crosslink. We will see where it leads. Hopefully it will get traction enough so it will get it's own scenario. Grazzolini (talk) 04:27, 23 March 2015 (UTC)Reply[reply]

Sorry for not replying for many days guys, I've tried to follow the discussion even if I'm a bit short of time (as always :P). I have to agree a bit with EscapedNull's rant though, as I said at this stage we have to start making the new scenario, so we can discuss on something more mergeable than this guide, which is already a valuable effort of course! That's why I've started User:Kynikos/Cryptodisk scenario draft, I'll try to improve it little by little, but you're all invited to contribute, I haven't created that page only for me to work on it :) — Kynikos (talk) 13:48, 23 March 2015 (UTC)Reply[reply]
You're right. I realized that cryptodisk would not be suitable for remote machines shortly after I posted that. GRUB already has networking code (for PXE boot, etc), but it has no remote administration interface, so one would need a remote management card (in the case of a server that supports them), or a physical keyboard. Cryptodisk might improve security on a server, but remote unlocking is just not a possibility without some serious GRUB (or hardware) hacking.
I just finished my GRUB cryptodisk with EFI/GPT in a VM, so I'll begin drafting the scenario very soon. This tutorial will be for new installations, but perhaps a conversion tutorial would be appropriate at some point. The draft is named User:EscapedNull/GRUB_Cryptodisk_UEFI_GPT for anyone who wants to add it to their watchlist. Feedback is appreciated!
Note: I didn't Kynikos's reply until I got an edit conflict trying to submit my reply (above). Since your draft is further along, I'll delete my page and work on yours. EscapedNull (talk) 16:33, 23 March 2015 (UTC)Reply[reply]
From what I saw, the Kynikos page is better organizes than mine. Keep note that I already added the sort/resize examples to Partitioning and there is a mention already of cryptodisk in GRUB page. I believe that some crosslinking is due. What you guys think is the best place to mention mkinitcpio-chkcryptoboot? I am still writing the code to detect boot bypass, it will ready soon. Kynikos, I will take a look at the scenario in your page. I already have some remarks. GRUB is slow opening a LUKS device with sha512. I believe it does not have support for cpu's AES-NI, since there is no kernel loaded yet to benefit from it. Grazzolini (talk) 20:36, 23 March 2015 (UTC)Reply[reply]
I would vote Dm-crypt/Specialties is the best place for mkinitcpio-chkcryptobootAUR. As for boot speed, I first used cryptsetup's default sha1, and it was taking about two seconds. Tested with --hash sha512, it might take three seconds. These are both tested under QEMU (not sure if it uses AES hardware acceleration at all) with cryptsetup defaults. For me, I wouldn't mind spending three seconds a month for some extra security. Besides, I'm no cryptographer, but I thought sha256 was designed to be a slow, iterative PBKDF primitive, while sha512 was designed to be a fast data hash. In other words, I didn't think the speed was necessarily a function of the output length. With all due respect, the default is sha1, so I wouldn't dwell on choosing the "right" hash spec when we have more important things to worry about right now. EscapedNull (talk) 10:29, 25 March 2015 (UTC)Reply[reply]

I've had a very busy week, but I am now back to start moving things along. I am finishing things with mkinitcpio-chkcryptobootAUR, just having some troubles with Desktop_notifications. By the way, I will contribute some changes to chkboot-gitAUR also, just don't know if the maintainer will pick them up. I don't hear back from him in weeks. As for your test results EscapedNull, if your host machine has AES-NI, your hypervisor will make use of them on the guest machine. I believe that it would make GRUB syscalls, even if originally not able to use it, use them under the hood, thus making it faster. I can measure a difference in the time to open a device with sha512 and a device formatted with sha256. Also, I don't think that cryptsetup --help cryptsetup defaults, specially using SHA1 are good enough. As I mentioned, it is a trade off. I am no cryptographer either, but as far as I know, sha256 is faster than sha512. Both are slower than sha1. Since hashing only is important when unlocking the device, I believe we can suggest using a better hash spec, as it is already done in the wiki. Either way, I am finishing moving things this week. So that we can have feedback from a more broader audience.
Grazzolini (talk) 14:44, 30 March 2015 (UTC)Reply[reply]
Grazzolini, in the scenario subpage we crosslink to Dm-crypt/Device_encryption#Encryption options for LUKS mode in each scenario so that readers are aware but keep commands in the examples to default. That's the place indeed. Regarding you observation I added [1]. I actually had no reference whether GRUB (outside hypervisor) has AES-NI or not (if someone has a reference please add it, thanks), but your observation suggests it: Whatever hash you used at LUKS blockdevice format made XYZ iterations. Now on boot the GRUB software implementation has to perform the same XYZ iterations without the hardware instructions. --Indigo (talk) 11:50, 12 April 2015 (UTC)Reply[reply]
Indigo, I took a look at the source code and couldn't find any usage of the hardware instruction set from within GRUB. At this moment, it is not AES-NI aware. I suspected because of the long unlock time. But, I took a look at the cryptsetup code, and, as far as I can tell, the AES-NI only kicks in, after the master key was successfully unlocked. Of course, with a kernel loaded, these operations are faster, because cryptsetup use the kernel primitives, which are optimized. AES-NI, in this context, would only make encryption/decryption operations faster, not unlock. I believe that the unlock from GRUB is slow, because it is a software only implementation. And, it is specific to them. I don't know if they can take shortcuts or not, nor if they primitives implementation can be improved or not. But using a smaller hash size and less iterations, seems to improve the boot speed. I will take a look and see if their code can be improved. But since we are talking about a boot loader which have a series of constrains and also has to be portable, I don't see much more optimization that can be done. I have been busy as hell, and that's the main reason why I didn't moved things. This is week I believe things will be a little bit less chaotic so I can finish moving things.
Grazzolini (talk) 16:04, 14 April 2015 (UTC)Reply[reply]
Well, the wiki is a strict no-(time)stress zone :) And you are right in that aes-ni itself is unrelated, I removed the speculation with [2] again. --Indigo (talk) 20:32, 14 April 2015 (UTC)Reply[reply]
Now that I have reached the minimal functionality I intended for mkinitcpio-chkcryptobootAUR, I can focus on finishing the content on the wiki. Just need to know if the content in User:Kynikos/Cryptodisk scenario draft should be used or if I can follow with grammar/tone changes of my own content and put it on the pointed places. It would be nice to hear from Kynikos or Indigo before I start moving things.
Grazzolini (talk) 19:53, 1 April 2015 (UTC)Reply[reply]
When ready the draft scenario in Kynikos' user page is meant to be moved for point (4) above, i.e. installation instructions. We are always keen to keep the verbose text in the scenarios low (short&concise install instructions) but crosslink explanations. That we want to crosslink to the other content from it later is good to have in mind, but that's the only thing regarding it.
It would be best to start with covering the points above (named (1a), (1b), (1c), (2a), (2b), etc.), i.e. what we agreed on as a base before. Don't worry about grammar/tone, just please remember ArchWiki:Contributing#The 3 fundamental rules (the first two:) and avoid first person statements perhaps. For your already written content, you could either copy/move a subsection from your user page in one edit and then adjust it in place with subsequent smaller edits, or edit it first to fit the destination, move it and just do final touches there. (Btw you can of course also put templates - like Kynikos did in the scenario - to make aware for expansions/needed input/help/etc). If you are unsure about how to best merge the content to the wiki/fit it, have a go with another part first (e.g. 5a to Dm-crypt/Specialties#mkinitcpio-hook, or 2a for Dm-crypt/Drive preparation#Boot partition .28GRUB.29) and wait for feedback. --Indigo (talk) 21:55, 1 April 2015 (UTC)Reply[reply]
Grazzolini, we are working on finalizing (4.) of above tasks in User:Kynikos/Cryptodisk scenario draft to merge it over to the scenario subpage. If you find time, read over it - that would be great. Any points you want to note can be left in User talk:Kynikos/Cryptodisk scenario_draft#Merge prerequisites.3F. Any changes you see important, feel free to edit the draft directly. --Indigo (talk) 18:08, 18 April 2015 (UTC)Reply[reply]

Edits to terminator

Hi, you recently removed some details in terminator regarding the two different versions available. I was just wondering your rationale was? After your edits, I think the page implies that the two versions are on the same branch (which is incorrect; they use different gtk and vte), and that the version in the official repository is just a tagged, stable version of the *-gtk3-bzr version (which is also incorrect; the former is deprecated). I've reverted it in the meantime, but mainly so that I don't forget. I am by no means heavily tied to this new version, so please feel to re-edit, or reply here with more details. Cheers, Ostiensis (talk) 00:00, 4 January 2017 (UTC)Reply[reply]

Hi, the terminator on official repositories is now using the official release of the gtk3 branch, check [3] and [4]. This is why I changed the terminator page, the package is now using that official first (pre?)release of the gtk3 branch. This was done because the old branch wouldn't receive bug report nor fixes and all development is being done on the gtk3 branch. Grazzolini (talk) 14:28, 4 January 2017 (UTC)Reply[reply]

Oops, sorry, I missed that update. I presumed that the official terminator would stay on the gtk2 branch, because it was the stable version. Apologies, and I've reverted the wiki back to your edits. Cheers, Ostiensis (talk) 23:03, 4 January 2017 (UTC)Reply[reply]

It probably would remain on that branch, but upstream no longer accept bugs for it. So the choice was let it rot, or update it and deal with possible breakage.

Grazzolini (talk) 00:11, 5 January 2017 (UTC)Reply[reply]