Bug 681250 - filesystem encrypted with cyrillic lang passphrase can not be decrypted at boot time
Summary: filesystem encrypted with cyrillic lang passphrase can not be decrypted at bo...
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 23
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: David Shea
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: https://fedoraproject.org/wiki/Common...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-03-01 14:52 UTC by Yulia Kopkova
Modified: 2015-09-01 15:03 UTC (History)
19 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-09-01 13:07:01 UTC


Attachments (Terms of Use)

Description Yulia Kopkova 2011-03-01 14:52:57 UTC
Description of problem:
Filesystem encrypted with cyrillic lang (Russian) passphrase can not be decrypted at boot time.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. During Fedora installation choose Russian as system language and keyboard layout
2. Create filesystem and set encryption passphrase with Russian keyboard layout.
3. Reboot and input passphrase on request
  
Actual results:
Filesystem is not decrypted at boot time

Expected results:
Filesystem decrypted at boot time

Additional info:

Comment 1 Yulia Kopkova 2011-03-01 14:55:13 UTC
dracut-008-7.fc15

Comment 2 Harald Hoyer 2011-03-01 15:15:45 UTC
what is your kernel command line?

Comment 3 Yulia Kopkova 2011-03-01 17:29:20 UTC
title Fedora (2.6.38-0.rc6.git6.1.fc15.x86_64)
	root (hd0,0)
	kernel /vmlinuz-2.6.38-0.rc6.git6.1.fc15.x86_64 ro root=/dev/mapper/vg-fedora rd_LVM_LV=vg/fedora rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=ru_RU.UTF-8 KEYTABLE=ru rhgb quiet
	initrd /initramfs-2.6.38-0.rc6.git6.1.fc15.x86_64.img

Comment 4 Harald Hoyer 2011-03-02 08:34:50 UTC
LANG=ru_RU.UTF-8 
KEYTABLE=ru

Is that the correct setting?

What is in /etc/sysconfig/i18n and /etc/sysconfig/keyboard?

Comment 5 Yulia Kopkova 2011-03-02 09:14:02 UTC
y(In reply to comment #4)
> LANG=ru_RU.UTF-8 
> KEYTABLE=ru
> 
> Is that the correct setting?
It seems correct to me.

> 
> What is in /etc/sysconfig/i18n and /etc/sysconfig/keyboard?

# cat /etc/sysconfig/i18n 
LANG="ru_RU.UTF-8"

# cat /etc/sysconfig/keyboard 
KEYTABLE="ru"
MODEL="pc105"
LAYOUT="ru,us"
OPTIONS="grp:shifts_toggle,grp_led:scroll"

Comment 6 Harald Hoyer 2011-03-02 09:34:57 UTC
I see rd_NO_LUKS ... so it seems, that your root is not encrypted. 
So, which volume is encrypted?

Can you post /etc/crypttab?

Comment 7 Yulia Kopkova 2011-03-02 09:53:20 UTC
On this installation root is not encrypted. It's another filesystem

# cat /etc/crypttab 
luks-f3b1a760-7a2e-4175-b51d-c9708aa41102 UUID=f3b1a760-7a2e-4175-b51d-c9708aa41102 none 

/dev/mapper/vg-fedora   /                       ext4    defaults        1 1
UUID=2628a2ab-4e5f-4074-bd7c-d45395677a5b /boot                   ext3    defaults        1 2
/dev/mapper/luks-f3b1a760-7a2e-4175-b51d-c9708aa41102 /data                   ext4    defaults        1 2

I also tried encryption with passphrase in Russian with root. Can not decrypt.

My understanding is that Russian layout is not set.

Passphrase set with English layout decrypt filesystem at boot time with the same environment as in Comment #5:

in kernel commandline
LANG=ru_RU.UTF-8 
KEYTABLE=ru

and

# cat /etc/sysconfig/i18n 
LANG="ru_RU.UTF-8"

# cat /etc/sysconfig/keyboard 
KEYTABLE="ru"
MODEL="pc105"
LAYOUT="ru,us"
OPTIONS="grp:shifts_toggle,grp_led:scroll"

Comment 8 Harald Hoyer 2011-03-02 10:30:39 UTC
If you add "rdbreak=initqueue rdshell" to the kernel command line, you will be dropped to a shell in the initramfs. 

Can you check, that the russian keyboard is not set?

And what version does:

# ls /dracut*

display in the initramfs shell? If it is older than dracut-008-7.fc15, you have to regenerate the initramfs.

Comment 9 Yulia Kopkova 2011-03-02 10:41:33 UTC
(In reply to comment #8)
> If you add "rdbreak=initqueue rdshell" to the kernel command line, you will be
> dropped to a shell in the initramfs. 
> 
> Can you check, that the russian keyboard is not set?
Confirmed. Russian keyboard is not set

> 
> And what version does:
> 
> # ls /dracut*
/dracut-008-7.fc15

> 
> display in the initramfs shell? If it is older than dracut-008-7.fc15, you have
> to regenerate the initramfs.

Comment 10 Harald Hoyer 2011-03-02 13:05:08 UTC
(In reply to comment #9)
> (In reply to comment #8)
> > If you add "rdbreak=initqueue rdshell" to the kernel command line, you will be
> > dropped to a shell in the initramfs. 
> > 
> > Can you check, that the russian keyboard is not set?
> Confirmed. Russian keyboard is not set

does this load the russian keyboard in the initramfs shell?

# loadkeys -u ru

Comment 11 Yulia Kopkova 2011-03-02 13:59:51 UTC
(In reply to comment #10)
> does this load the russian keyboard in the initramfs shell?
> 
> # loadkeys -u ru
Loading /lib/kbd/keymaps/i386/qwerty/ru.map.gz

But keyboard is still english.

Comment 12 Harald Hoyer 2011-03-02 14:13:23 UTC
(In reply to comment #11)
> (In reply to comment #10)
> > does this load the russian keyboard in the initramfs shell?
> > 
> > # loadkeys -u ru
> Loading /lib/kbd/keymaps/i386/qwerty/ru.map.gz
> 
> But keyboard is still english.

ok, then that is another issue ...

does it work without "-u" ?

# loadkeys ru


Reassigning to kbd package.

Comment 13 Yulia Kopkova 2011-03-02 14:33:16 UTC
(In reply to comment #12)
> 
> does it work without "-u" ?
> 
> # loadkeys ru
> 
Nope

> 
> Reassigning to kbd package.
>
Thank you for looking into it, Harald!

Comment 14 Vitezslav Crhonek 2011-03-08 08:54:25 UTC
(In reply to comment #11)
> (In reply to comment #10)
> > does this load the russian keyboard in the initramfs shell?
> > 
> > # loadkeys -u ru
> Loading /lib/kbd/keymaps/i386/qwerty/ru.map.gz
> 
> But keyboard is still english.

From what you guess so? It seems that "loadkeys" works as expected - unfortunately "dumpkeys" is not available in the initramfs shell to see uploaded kyetable, but it's obvious from loading some qwertz keymap (e.g. "loadkeys -u cz"). Another point is, that national specific characters are not displayed because of initramfs shell font limitation (e.g. with ru keymap, squares instead of AltGr accessible national specific characters).

AFAIK it's not possible to decrypt LUKS encrypted filesystems with such passphrases during boot time, adding cryptsetups-luks maintainer to the CC to confirm or refute it.

Comment 15 Yulia Kopkova 2011-03-08 09:08:46 UTC
Vitezslav, thank you for comment.

Comment 16 Milan Broz 2011-03-08 11:01:35 UTC
All the passphrase reading is in plymouth dialog.
crypsetup just receives final string - and there is no limitation in charset.

So if there is problem with entering specific characters it is problem in implementation of that passphrase dialog box, not cryptsetup itself.

Comment 17 Harald Hoyer 2011-03-08 12:36:31 UTC
(In reply to comment #11)
> Another point is, that national specific characters are not
> displayed because of initramfs shell font limitation (e.g. with ru keymap,
> squares instead of AltGr accessible national specific characters).

BTW, you can set SYSFONT=<fontname> alias vconsole.font=<fontname> via the kernel command line and dracut will load this font.

Comment 18 Vitezslav Humpa 2011-03-09 15:21:30 UTC
Originally I wanted to report a new bug, but this is quite likely related to this. Certain layouts selected during install are ignored by the system (GNOME etc. get's them fine, I am mean e.g. in tty).

Proper option is passed to kernel (in my case KEYTABLE=cz-lat2) on bootup and /etc/sysconfig/keyboard also seems to be configured properly.
However in tty2 etc., english layout is used.

This relates to bug 68290 and also this bug as user is unable to type his disk encryption password if it had non-english characters, but that is just a side-effect of not honoring settings for SOME of the layouts. This behavior occurred when setting cz-querty layout and the default Slovak, 
which are the ones I tried so far. With standard cz layout (qwertz), there was no problem.

I tested this on latest F15 branch.

Comment 19 Vitezslav Crhonek 2011-03-10 11:36:10 UTC
(In reply to comment #18)
> Originally I wanted to report a new bug, but this is quite likely related to
> this. Certain layouts selected during install are ignored by the system (GNOME
> etc. get's them fine, I am mean e.g. in tty).
> 
> Proper option is passed to kernel (in my case KEYTABLE=cz-lat2) on bootup and
> /etc/sysconfig/keyboard also seems to be configured properly.
> However in tty2 etc., english layout is used.
> 
> This relates to bug 68290 and also this bug as user is unable to type his disk
> encryption password if it had non-english characters, but that is just a
> side-effect of not honoring settings for SOME of the layouts. This behavior
> occurred when setting cz-querty layout and the default Slovak, 
> which are the ones I tried so far. With standard cz layout (qwertz), there was
> no problem.
> 
> I tested this on latest F15 branch.

Please take a look at cz-lat2 keymap (/lib/kbd/keymaps/i386/qwerty/cz-lat2.map.gz). By default this keymap acts as US map. To get Czech characters you have to switch mode with "Pause" key (or use AltGr). Usage of both Slovak qwerty keymaps is similar.

Works for me, tested on F15 Alpha with latest kbd-1.15.2-2.

Comment 20 Vitezslav Crhonek 2011-03-10 12:10:45 UTC
(In reply to comment #17)
> (In reply to comment #11)
> > Another point is, that national specific characters are not
> > displayed because of initramfs shell font limitation (e.g. with ru keymap,
> > squares instead of AltGr accessible national specific characters).
> 
> BTW, you can set SYSFONT=<fontname> alias vconsole.font=<fontname> via the
> kernel command line and dracut will load this font.

Harald, with SYSFONT=latarcyrheb-sun16 (or vconsole.font=latarcyrheb-sun16) in kernel command line there are still "squares" instead of some non-english characters in the initramfs shell.

But when I reload the font within the initramfs shell again with "setfont /lib/kbd/consolefonts/latarcyrheb-sun16.psfu.gz", then everything displays correctly. Is that OK?

Comment 21 Vitezslav Crhonek 2011-03-10 12:23:04 UTC
(In reply to comment #16)
> All the passphrase reading is in plymouth dialog.
> crypsetup just receives final string - and there is no limitation in charset.
> 
> So if there is problem with entering specific characters it is problem in
> implementation of that passphrase dialog box, not cryptsetup itself.

Adding plymouth maintainer to the CC. Is plymouth able to handle all characters, or the set is restricted?

Comment 22 Erik Johnson 2011-07-24 23:21:03 UTC
I would like to add that while my problem is not a luks/boot keyboard problem,  I'm having a similar issue since switching to FC15, loadkeys does absolutely nothing.  It claims "Loading /lib/kbd/keymaps/i386/qwerty/de.map.gz" but typing reveals the layout is still "us" and the layout doe not change.  My /etc/sysconfig/keyboard is also configured for "de"

Comment 23 Fedora End Of Life 2012-08-07 19:10:24 UTC
This message is a notice that Fedora 15 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 15. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '15' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 15 reached end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 24 Petr Schindler 2015-05-20 12:59:13 UTC
This bug still occurs in f22 Final RC1. When I install in russian there are two keyboard layouts set - russian (default) and english (so you could set username in ascii I guess).

After installation, if I boot to gnome everything seems to be alright. Russian layout is set by default and there is also English layout. But during boot and in tty2 in console the English layout is used. This is a big problem in systems without graphic (for example server) because user sets password using default layout (which is Russian during installation). User is even noticed that he may not be able to switch layouts when needed (I would expect that default layout is used in that case).

I tested the same with czech layout and I used non ascii symbol č in password for disk encryption. In that case everything works as expected and I was able to decrypt disk.

I propose this bug as blocker as it violates (quite clearly) the final criterion: "If a particular keyboard layout has been configured for the system, that keyboard layout must be used: When unlocking encrypted storage volumes during boot

Comment 25 Jaroslav Reznik 2015-05-20 13:21:15 UTC
-1 blocker, this is an old bug, not a regression and added later in the cycle to criteria (cyryllic tests). It would be nice to get fix to F22 but realistically +1 blocker for F23 final so we don't forget it.

Comment 26 Kevin Fenzi 2015-05-20 13:25:44 UTC
Yeah, -1 blocker for f22, but we should fix for f23 definitely.

Comment 27 Kamil Páral 2015-05-20 13:31:50 UTC
This has gone long unnoticed. Even though it violates the criteria, we've found out way too late and we're not likely to fix this unless we delay the release a lot. -1 blocker for F22, +1 blocker for F23.

Per votes above, rejecting as a blocker for F22 and accepting as a blocker for F23.

Comment 28 Petr Schindler 2015-05-22 10:43:44 UTC
The same thing happens to Arabic layouts too (for example Persian). I followed test case: https://fedoraproject.org/wiki/QA:Testcase_Arabic_Language_Install and I wasn't able to decrypt the disc even though correct LANG parameter is set on kernel line.

Comment 29 Petr Schindler 2015-08-14 05:45:24 UTC
I tested arabic language for password again and after reboot the disk still can't be decrypted.

I think that English keyboard layout should be set as default for languages which use non-ASCII keyboard layouts. The main reason is that when you would like to login you would still need a ASCII characters for writing user name (as it has to be in ASCII). When Arabic layout is used then user wouldn't be able to login to terminal (which is default for Server for example).

Comment 30 Marko Myllynen 2015-08-14 06:15:38 UTC
(In reply to Petr Schindler from comment #29)
> 
> I think that English keyboard layout should be set as default for languages
> which use non-ASCII keyboard layouts. The main reason is that when you would
> like to login you would still need a ASCII characters for writing user name
> (as it has to be in ASCII). When Arabic layout is used then user wouldn't be
> able to login to terminal (which is default for Server for example).

This is also somewhat related:

https://bugzilla.redhat.com/show_bug.cgi?id=1209460

Thanks.

Comment 31 David Shea 2015-08-27 21:02:59 UTC
In short, this is unfixable. 

The LUKS passphrase is typed in using the vconsole keymap, and the vconsole keymap has to support ASCII in order to be useful. Even in a locale that uses a non-Latin script, the user's username and most everything on the command-line are going to be ASCII, which is why when a locale is selected where the default does not support ASCII (according to langtable.supports_ascii), 'us' is appended to the keyboard list. When in a GUI, this dual-layout setup isn't completely terrible: there's an indicator--in anaconda and usually in the eventual desktop environment--of what the current layout is, and there are keyboard shortcuts to switch layouts. The vconsole has neither of those things, so to make interacting with the vconsole possible, /etc/vconsole.conf gets KEYMAP=us.

Using the tools we currently have, you cannot have a LUKS password that uses a non-Latin keyboard layout. There is no way to specify a separate keymap for the password, so if anaconda were to set, for example, KEYMAP=ru in vconsole.conf and something caused dracut to boot to an emergency shell, you would not be able to interact with the shell in any meaningful way. If we set KEYMAP=ru and you booted to a text console, you would not be able to login. And of course all of this needs to happen well before any kind of graphical environment.

There is a warning displayed if you attempt to set a non-ASCII password. I suppose that what needs to be done is to examine things more closely and turn this into an error. If you attempt to set a LUKS passphrase using characters that cannot be typed in your vconsole keymap, anaconda should not accept that passphrase.

Comment 32 David Shea 2015-08-28 17:51:35 UTC
Some of what I said above is not entirely correct, and some of the information reported by the tools we depend on is not entirely correct.

In particular, the ru vconsole keymap can type ascii characters, and in fact does so by default. If I run 'loadkeys ru' from the command line, I get a US/qwerty keymap on levels 1&2, and a Russian/cyrillic (йцукен) keymap on levels 3&4. Other non-latin keymaps appear to do the same. It may surprise the user that they need to hold AltGr to type a cyrillic passphrase at boot time when they did not AltGr to type it originally in the GUI. Maybe this is not a surprise. I don't know.

But that's with loadkeys. If I boot with KEYMAP=ru in /etc/vconsole.conf and let localed configure things, I get a keymap with US/qwerty on levels 1&2 and nothing at all on levels 3&4. So we're back where started and unable to type a cyrillic passphrase.

I would like to propose that this bug no longer be considered a blocker for the following reasons:

1) This isn't new behavior. The bug was reported in 2011 and it's probably been around for a lot longer than that.

2) There are a lot of pieces involved, and it's not entirely clear which ones are wrong about what. Maybe langtable should not be reporting supports_ascii=False for ru. Maybe it shouldn't be reporting supports_ascii=False for anything. Maybe systemd-localed isn't setting the keyboard right from vconsole.conf. Maybe the plymouth password input needs to display more information about what exactly the keymap is and how it differs from the X11 keymap. There are a lot of questions here and I don't think they're all going to get answered in a short period of time, and any changes to all of this behavior need extensive testing and not just a rush to Final.

3) The new error messages I proposed in comment 31 would require string changes, and Fedora 23 is past string freeze. Given that these strings would be entirely about the situation in non-English locales, I don't think that adding this as a last minute new string is the best idea.

4) There's already a warning displayed when you use a non-ASCII passphrase.

Comment 33 Kamil Páral 2015-08-28 18:49:39 UTC
(In reply to David Shea from comment #32)
> In particular, the ru vconsole keymap can type ascii characters, and in fact
> does so by default. If I run 'loadkeys ru' from the command line, I get a
> US/qwerty keymap on levels 1&2, and a Russian/cyrillic (йцукен) keymap on
> levels 3&4. Other non-latin keymaps appear to do the same. It may surprise
> the user that they need to hold AltGr to type a cyrillic passphrase at boot
> time when they did not AltGr to type it originally in the GUI. Maybe this is
> not a surprise. I don't know.

I can't speak for Russian, but I believe we have a similar situation with one of the Czech layouts. Personally, I never know how to switch layouts when I'm in a console, and I had no idea AltGr might switch the modes temporarily (it might be even specific just for some keymaps). And that's me, a long time Linux user. So I'd rather call this a surprising behavior, than expecting that all Russian/Czech/etc users know about this.

> 3) The new error messages I proposed in comment 31 would require string
> changes, and Fedora 23 is past string freeze. Given that these strings would
> be entirely about the situation in non-English locales, I don't think that
> adding this as a last minute new string is the best idea.

Do I understand correctly that this feature (don't allow non-ascii chars in encryption passphrase) would "solve" this whole thing? If that's the case, I would consider it a great candidate for a string freeze exception. It's better to have an untranslated error that prevents you from inputting non-ascii chars, than accepting such a password and making it impossible for the user to boot at all. A potentially untranslated error string is a smaller nuisance than highly likely broken boot. Am I missing something?

Comment 34 Adam Williamson 2015-08-31 16:35:33 UTC
I think we *used* to disallow non-ASCII passphrases (and possibly usernames and passwords) and then it was requested that that be changed at some point. But personally I think requiring ASCII (or rather, passphrase that can be typed on a 'US' console layout) is a pretty sensible idea given all the pain that exists in this area.

David: you may need to re-generate the initramfs after fiddling with /etc/vconsole.conf , it's been a while since I fiddled with this stuff so I don't know for sure.

Kamil: the switch key (or combo) varies between layouts, it tends to be whatever users in that country are used to from ($SOME_RANDOM_THING_THEY_USED_IN_THE_1980S), AIUI. What I've been told for countries where switched layouts are commonly used is that users expect one to be used and they expect it to start in Latin mode (since you're more often going to need to type Latin characters at a console, especially during boot / login). I think Czech is a bit different because AIUI most Czech people don't actually use a switched layout, the switched layout is more of a variant?

Comment 35 Adam Williamson 2015-08-31 17:42:14 UTC
Re-considered at 2015-08-31 blocker review meeting: https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2015-08-31/f23-blocker-review.2015-08-31-16.01.log.txt . This bug is now rejected as a blocker.

There's a whole lot of background detail here, but the most important conclusion is this:

Console and X/Wayland keyboard input mechanisms differ significantly. We can know that there are cases where the layout used during graphical installation will be able to type characters that the layout used at the console in the installed system will not be able to type. However, it is difficult for anaconda to know with certainty which layouts these will be, and which characters the console layout will and will not be capable of inputting in each such case. We also cannot know (in each case) whether the user is aware of how to input all characters both in X and at the console.

Given the above, it's not realistically possible for anaconda to allow non-ASCII passphrases in a 100% 'safe' way. It has some choices:

1. Allow non-ASCII passphrases unconditionally (but with a warning, as it currently does) and rely on the user being aware of the details of console input for their language
2. Simply disallow non-ASCII passphrases
3. Try to require that an ASCII-capable layout is selected in anaconda when typing the passphrase (and assume that any character than can be input with that layout will also be available with whatever console layout is chosen post-install)

We don't think it's appropriate under the blocker process to mandate any of those choices on anaconda's part, thus this bug is not a blocker. In an ideal world it would be possible for the installer to ensure the user could only choose a passphrase that they would always be able to input later, and if it did not do so that *would* be a blocker, but unfortunately at present we do not live in that world.

Comment 36 Ray Strode [halfline] 2015-08-31 18:23:52 UTC
So one feature luks has is the ability to assign more than one passphrase to the same target device.  One idea to get around the keyboard layout issue would be to add two passphrases, one for each layout.

Comment 37 David Shea 2015-09-01 13:07:01 UTC
After some more thought and discussion on this: this cannot be fixed in anaconda. We cannot know with the current tools whether a given X keymap and a given VC keymap are considered equivalent, attempting to establish an equivalence between keymaps is shaky at best, and even if we were able to establish all of that you can still copy and paste something untypable. This issue could be solved in any number of places: dracut+plymouth could allow switching keymaps while typing the password, systemd could create console keymaps equivalent to X keymaps, kmscon could get X and the console using the same keymap and make this all less of a problem in the first place. anaconda is not one of those places.

Anaconda displays a warning when you use non-ASCII characters in a passphrase. It used to reject non-ASCII characters, but it was decided that was too draconian and I would rather not go back to it.

Comment 38 Adam Williamson 2015-09-01 15:03:12 UTC
For the record:

"systemd could create console keymaps equivalent to X keymaps"

we do this already in the kbd package, but we intentionally throw away conversions of non-ASCII-capable layouts. I don't think anyone wanted to take on the work of 'convert a common Xkb non-Latin layout plus Latin layout plus switcher key configuration to a single kbd layout using levels' - that's rather a tricky job, I think.


Note You need to log in before you can comment on or make changes to this bug.