from:"Evgeny Kapun"

Bug#1068885: Upgrading python3-fife to 0.4.2-6+b1 breaks unknown-horizons

2024-04-12 Thread Evgeny Kapun


Package: python3-fife

Version: 0.4.2-6+b1


After upgrading python3-fife to version 0.4.2-6+b1, unknown-horizons 
fails to launch. The following exception is printed:



Traceback (most recent call last):
  File "/usr/games/unknown-horizons", line 381, in 
    main()
  File "/usr/games/unknown-horizons", line 109, in main
    import horizons.main
  File "/usr/lib/python3/dist-packages/horizons/main.py", line 46, in 


    from horizons.gui import Gui
  File "/usr/lib/python3/dist-packages/horizons/gui/__init__.py", line 
22, in 

    from .gui import Gui
  File "/usr/lib/python3/dist-packages/horizons/gui/gui.py", line 30, 
in 
    from horizons.component.ambientsoundcomponent import 
AmbientSoundComponent
  File 
"/usr/lib/python3/dist-packages/horizons/component/ambientsoundcomponent.py", 
line 24, in 

    from fife.fife import AudioSpaceCoordinate
ImportError: cannot import name 'AudioSpaceCoordinate' from 'fife.fife' 
(/usr/lib/python3/dist-packages/fife/fife.py)



It works fine with version 0.4.2-6.

Bug#1056948: coq-doc-html loads files from a CDN

2023-11-26 Thread Evgeny Kapun


Package: coq-doc-html

Version: 8.17.1-1


The HTML files in the coq-doc-html package contain the following line:

src="https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-mml-chtml.js";>


They should use a local library instead.

Bug#965154: maxima: insecure use of /tmp 2020-07-16 Thread Evgeny Kapun Package: maxima Version: 5.43.2-3 Severity: grave Tags: security Maxima uses /tmp in an insecure way. In particular, when creating plots, files are written to maxima_tempdir (which defaults to /tmp) with predictable names, and there is no check that the files do not exist. An attacker could use symlinks to redirect the writes to an arbitrary file. Bug#964471: libreoffice-l10n-ru: error when configuring: cp: cannot create regular file '/etc/libreoffice/registry/Langpack-ru.xcd': No such file or directory 2020-07-07 Thread Evgeny Kapun On 07.07.2020 22:40, Rene Engelhard wrote: Even that worked for me in said testing VM "upgraded" to unstable with your apt-get --with-new-pkgs upgrade. libreoffice-l10n-de, libreoffice-l10n-ru and other LO packages were kept back. After some testing, I found out that you also need to pass `--no-install-recommends`, as otherwise `Recommends: libreoffice-core (>> 1:7.0.0~rc1)` in libreoffice-l10n-ru prevents it from upgrading. Anyway, upgrading any subset of packages, if permitted by dependencies, should not produce any errors. To test that this is indeed the case, I suggest running `apt-get --no-install-recommends install $pkg` in a test environment for every package to test the upgrade of that package in isolation (so that only the package and the packages that are strictly required to satisfy dependencies are upgraded). Bug#964471: libreoffice-l10n-ru: error when configuring: cp: cannot create regular file '/etc/libreoffice/registry/Langpack-ru.xcd': No such file or directory 2020-07-07 Thread Evgeny Kapun Package: libreoffice-l10n-ru Version: 1:7.0.0~rc1-3 Severity: serious When upgrading Libreoffice, the following errors occur: Setting up libreoffice-l10n-ru (1:7.0.0~rc1-3) ... Creating config file /etc/libreoffice/registry/Langpack-ru.xcd with new version cp: cannot create regular file '/etc/libreoffice/registry/Langpack-ru.xcd': No such file or directory dpkg: error processing package libreoffice-l10n-ru (--configure): installed libreoffice-l10n-ru package post-installation script subprocess returned error exit status 1 dpkg: dependency problems prevent configuration of libreoffice-help-ru: libreoffice-help-ru depends on libreoffice-l10n-ru; however: Package libreoffice-l10n-ru is not configured yet. dpkg: error processing package libreoffice-help-ru (--configure): dependency problems - leaving unconfigured Errors were encountered while processing: libreoffice-l10n-ru libreoffice-help-ru This is apparently caused by /etc/libreoffice/registry not existing. Bug#960709: unattended-upgrades: Exception: 'NoneType' object has no attribute 'dependencies' 2020-05-15 Thread Evgeny Kapun Package: unattended-upgrades Version: 1.11.2 I'm using unattended-upgrades on a Debian Buster system. Some time ago, it stopped working. When run from terminal, it prints: Exception: 'NoneType' object has no attribute 'dependencies' This line doesn't appear in logs. After some manual editing, I managed to pull a stack trace: Traceback (most recent call last): File "/usr/bin/unattended-upgrade", line 1208, in do_install options.verbose or options.debug) File "/usr/bin/unattended-upgrade", line 651, in upgrade_in_minimal_steps for pkgname in upgrade_order(to_upgrade, cache): File "/usr/bin/unattended-upgrade", line 810, in upgrade_order len(transitive_dependencies(pkg, cache).intersection(to_upgrade)) File "/usr/bin/unattended-upgrade", line 793, in transitive_dependencies transitive_dependencies(cache[base_dep.name], cache, acc) File "/usr/bin/unattended-upgrade", line 793, in transitive_dependencies transitive_dependencies(cache[base_dep.name], cache, acc) File "/usr/bin/unattended-upgrade", line 793, in transitive_dependencies transitive_dependencies(cache[base_dep.name], cache, acc) [Previous line repeated 5 more times] File "/usr/bin/unattended-upgrade", line 788, in transitive_dependencies for dep in pkg.candidate.dependencies: AttributeError: 'NoneType' object has no attribute 'dependencies' Bug#941700: [Pkg-javascript-devel] Bug#941700: Bug#941700: Update babel to version 7 2019-10-09 Thread Evgeny Kapun [14:53:55] ReferenceError: [BABEL] /home/pravi/forge/debian/git/js-team/node-babel/packages/babel-parser/src/x.js: Unknown option: base.envName. Check out for more information about options. The reason for this error and other errors is that this version uses multiple Babel features introduced in Babel 7, such as: * envName option [1] * babel.config.js file [2] * Numeric separator [3] For these reasons, it doesn't seem possible to build Babel 7.4.5 using Babel 6. I see two possible ways to solve this: 1. Bootstrap Babel manually, that is, build it locally using Babel installed from NPM and upload the resulting binary packages. 2. First package an older version of Babel, such as 7.0.0, then use it to build the current version. Some other notes: * The version being packaged is 7.4.5, but the latest stable version is already 7.6.0. * During build, it is better to set NODE_ENV=production, because otherwise it will build for the current version of Node, so the resulting code may not run on older versions. With NODE_ENV=production, it will build for Node 6.9 and later (this is specified in babel.config.js). [1]: https://babeljs.io/docs/en/options#envname [2]: https://babeljs.io/docs/en/config-files#root-babelconfigjs-files [3]: https://babeljs.io/docs/en/babel-plugin-proposal-numeric-separator Bug#941900: Update Warzone 2100 to version 3.3 2019-10-07 Thread Evgeny Kapun Package: warzone2100 Version: 3.2.1-4 Warzone 2100 version 3.3 is available, and it includes fixes for various problems with version 3.2. The new version should be packaged in Debian. Bug#929829: gulp 4 cannot build node-babel 7 - Cannot convert undefined or null to object 2019-10-05 Thread Evgeny Kapun [15:37:17] Cannot convert undefined or null to object After checking the code, I found the root cause of this error. The error is caused by NPM package now-and-later, which is included in Debian package gulp version 4.0.2-2. The version included is 1.0.0. It should be upgraded to at least version 2.0.0. Gulp will not work with version 1.0.0 due to incompatible API change. After replacing the package with version 2.0.1 downloaded from NPM, the error disappears. Also, perhaps all those packages bundled with gulp should be in separate Debian packages instead. Bug#941700: Update babel to version 7 2019-10-03 Thread Evgeny Kapun Source: node-babel Version: 6.26.0+dfsg-3 Severity: important Babel 7 was released more than a year ago, so perhaps it's time to package the new version. Bug#914153: Update to version 2.3.0-3 breaks Megaglest 2018-11-19 Thread Evgeny Kapun Package: libftgl2 Version: 2.3.0-3 After updating libftgl2 from version 2.1.3~rc5-5 to version 2.3.0-3, text rendering in Megaglest is broken. Text is shown correctly in menus, but text displayed in the game itself is replaced by white rectangles. Bug#913137: virtualbox: VirtualBox E1000 Guest-to-Host Escape 2018-11-08 Thread Evgeny Kapun Control: severity -1 critical Raising severity because this bug can be used by any local user to elevate privileges. Also, before this bug is fixed upstream, it is possible to use this patch as a band-aid: --- a/src/VBox/Devices/Network/DevE1000.cpp +++ b/src/VBox/Devices/Network/DevE1000.cpp @@ -4343,6 +4343,7 @@ { /* Calculate how many bytes we have left in this TCP segment */ uint32_t cb = u16MaxPktLen - pThis->u16TxPktLen; +if (u16MaxPktLen < pThis->u16TxPktLen) abort(); if (cb > cbFragment) { /* This descriptor fits completely into current segment */ @@ -4409,6 +4410,7 @@ { /* Calculate how many bytes we have left in this TCP segment */ uint32_t cb = u16MaxPktLen - pThis->u16TxPktLen; +if (u16MaxPktLen < pThis->u16TxPktLen) abort(); if (cb > pDesc->data.cmd.u20DTALEN) { /* This descriptor fits completely into current segment */ This will crash the hypervisor if an exploit is attempted, preventing memory corruption. Also, I've attached the report, in case the original link stops working. ## Why I like VirtualBox and it has nothing to do with why I publish a 0day vulnerability. The reason is my disagreement with contemporary state of infosec, especially of security research and bug bounty: 1) Wait half a year until a vulnerability is patched is considered fine. 2) In the bug bounty field these are considered fine: 1) Wait more than month until a submitted vulnerability is verified and a decision to buy or not to buy is made. 2) Change the decision on the fly. Today you figured out the bug bounty program will buy bugs in a software, week later you come with bugs and exploits and receive "not interested". 3) Have not a precise list of software a bug bounty is interested to buy bugs in. Handy for bug bounties, awkward for researchers. 4) Have not precise lower and upper bounds of vulnerability prices. There are many things influencing a price but researchers need to know what is worth to work on and what is not. 3) Delusion of grandeur and marketing bullshit: naming vulnerabilities and creating websites for them; making a thousand conferences in a year; exaggerating importance of own job as a security researcher; considering yourself "a world saviour". Come down, Your Highness. I'm exhausted of the first two, therefore my move is full disclosure. Infosec, please move forward. ## General Information **Vulnerable software:** VirtualBox 5.2.20 and prior versions. **Host OS:** any, the bug is in a shared code base. **Guest OS:** any. **VM configuration:** default (the only requirement is that a network card is Intel PRO/1000 MT Desktop (82540EM) and a mode is NAT). ## How to protect yourself Until the patched VirtualBox build is out you can change the network card of your virtual machines to PCnet (either of two) or to Paravirtualized Network. If you can't, change the mode from NAT to another one. The former way is more secure. ## Introduction A default VirtualBox virtual network device is Intel PRO/1000 MT Desktop (82540EM) and the default network mode is NAT. We will refer to it E1000. The E1000 has a vulnerability allowing an attacker with root/administrator privileges in a guest to escape to a host ring3. Then the attacker can use existing techniques to escalate privileges to ring 0 via /dev/vboxdrv. ## Vulnerability Details ### E1000 101 To send network packets a guest does what a common PC does: it configures a network card and supplies network packets to it. Packets are of data link layer frames and of other, more high level headers. Packets supplied to the adaptor are wrapped in Tx descriptors (Tx means transmit). The Tx descriptor is data structure described in the 82540EM datasheet (317453006EN.PDF, Revision 4.0). It stores such metainformation as packet size, VLAN tag, TCP/IP segmentation enabled flags and so on. The 82540EM datasheet provides for three Tx descriptor types: legacy, context, data. Legacy is deprecated I believe. The other two are used together. The only thing we care of is that context descriptors set the maximum packet size and switch TCP/IP segmentation, and that data descriptors hold physical addresses of network packets and their sizes. The data descriptor's packet size must be lesser than the context descriptor's maximum packet size. Usually context descriptors are supplied to the network card before data descriptors. To supply Tx descriptors to the network card a guest writes them to Tx Ring. This is a ring buffer residing in physical memory at a predefined address. When all descriptors are written down to Tx Ring the guest updates E1000 MMIO TDT register (Transmit Descriptor Tail) to tell the host there are new descriptors to handle. ### Input Consider the following array of Tx descriptors: ``` [context_1, data_2, data_3, context_4, data_5] ``` Let's assign their structure fields as follows (field names are hypothe Bug#902897: virtualbox: fails to start vm (VERR_LDRELF_RELOCATION_NOT_SUPPORTED) 2018-07-16 Thread Evgeny Kapun Control: fixed -1 5.2.14-dfsg-7 Seems to be fixed now. Bug#902897: virtualbox: fails to start vm (VERR_LDRELF_RELOCATION_NOT_SUPPORTED) 2018-07-16 Thread Evgeny Kapun Control: notfixed -1 5.2.14-dfsg-5 I also still see this bug with the latest version. Bug#903580: aegisub can't be installed on unstable anymore 2018-07-11 Thread Evgeny Kapun Package: aegisub Version: 3.2.2+dfsg-3+b6 Severity: grave For some time already, Aegisub can't be installed on Debian unstable due to broken dependencies. Bug#902897: virtualbox: fails to start vm (VERR_LDRELF_RELOCATION_NOT_SUPPORTED) 2018-07-09 Thread Evgeny Kapun To install old package versions, there is snapshot.d.o [1]. Basically, it has a copy of every state Debian repository was ever in. There is also a way to see every version of every package and to find the appropriate snapshot to install it from. [1] https://snapshot.debian.org/ Bug#902897: virtualbox: fails to start vm (VERR_LDRELF_RELOCATION_NOT_SUPPORTED) 2018-07-08 Thread Evgeny Kapun On 08.07.2018 22:54, Steven R. Wright wrote: This is a critical enough bug to warrant removing 5.2.14-dfsg-1 from the repos. I have to do selective upgrades now to avoid pulling it in. Unstable repo is called unstable for a reason. If you want a system that doesn't break, use stable (you can install VirtualBox from backports) or testing. Bug#902897: virtualbox: fails to start vm (VERR_LDRELF_RELOCATION_NOT_SUPPORTED) 2018-07-04 Thread Evgeny Kapun Control: severity -1 serious This bug affects me as well. I was not able to start any VMs because of this error. Raising the severity to prevent this from migrating to testing. Bug#901409: Very low FPS in Nexuiz after Darkplaces upgrade 2018-06-12 Thread Evgeny Kapun On 12.06.2018 22:28, Simon McVittie wrote: On Tue, 12 Jun 2018 at 21:27:06 +0300, Evgeny Kapun wrote: After I upgraded Darkplaces to version 0~20180412~beta1-2 (from 0~20140513+svn12208-7), Nexuiz slowed down to about 8 frames per second, which made it unplayable. With the previous version, I could get 30-40 FPS on most maps. What video hardware is this on? Are you using X11 or Wayland or what? Which desktop environment, if any? Would you be able to try an intermediate version from <http://snapshot.debian.org/package/darkplaces/0%7E20170829%7Ebeta1-1/>? That might help to locate what has caused that slowdown. smcv Video hardware: Mobile Intel GM45 Express Chipset. Software: X.Org X Server 1.19.6. Desktop environment: LXDE. Version 0~20170829~beta1-1 is also slow, so the regression is between versions 0~20140513+svn12208-7 and 0~20170829~beta1-1. Bug#901409: Very low FPS in Nexuiz after Darkplaces upgrade 2018-06-12 Thread Evgeny Kapun Package: darkplaces Version: 0~20180412~beta1-2 Severity: important After I upgraded Darkplaces to version 0~20180412~beta1-2 (from 0~20140513+svn12208-7), Nexuiz slowed down to about 8 frames per second, which made it unplayable. With the previous version, I could get 30-40 FPS on most maps. Bug#898660: Telegram can't connect to the servers 2018-05-14 Thread Evgeny Kapun Package: telegram-desktop Version: 1.2.17-1 Severity: important Forwarded: https://github.com/telegramdesktop/tdesktop/issues/4652 Control: found -1 1.1.23-1~bpo9+1 There is an issue in Telegram Desktop which can make it impossible to connect to the servers [1]. This issue doesn't affect the latest upstream version, so this should probably be resolved by updating the Debian version. [1] https://github.com/telegramdesktop/tdesktop/issues/4652 Bug#876644: Is this bug still reproducible? 2018-03-15 Thread Evgeny Kapun Control: tags -1 - moreinfo On 15.03.2018 18:49, Lisandro Damián Nicanor Pérez Meyer wrote: OK. Do you have qt5ct installed? if not, can you try and install it? I want to be sure this is a bug somewhere and not just the lack of the proper QPA. The bug is still reproducible, even if I install and run qt5ct and set QT_QPA_PLATFORMTHEME=qt5ct when running affected programs. Bug#876644: Is this bug still reproducible? 2018-03-15 Thread Evgeny Kapun Control: tags -1 - moreinfo Control: found -1 5.9.2+dfsg-12 On 14.03.2018 22:25, Lisandro Damián Nicanor Pérez Meyer wrote: Hi! Can you still reproduce this bug with current Debian testing? Hi! This bug is still reproducible with version 5.9.2+dfsg-12. Bug#890999: VirtualBox modules built against headers version 4.14.17-1 cannot be loaded by kernel version 4.14.13-1: Unknown symbol __x86_indirect_thunk_r15 (err 0) 2018-02-21 Thread Evgeny Kapun Package: linux-headers-4.14.0-3-amd64 Version: 4.14.17-1 When I build VirtualBox kernel modules using linux-headers-4.14.0-3-amd64 version 4.14.17-1, the resulting modules can't be loaded using linux-image-4.14.0-3-amd64 version 4.14.13-1. When I build the same modules using headers version 4.14.13-1, they load successfully. Here are some error messages: systemd[1]: Starting LSB: VirtualBox Linux kernel module... kernel: vboxdrv: Unknown symbol __x86_indirect_thunk_r15 (err 0) kernel: vboxdrv: Unknown symbol __x86_indirect_thunk_rax (err 0) kernel: vboxdrv: Unknown symbol __x86_indirect_thunk_rdx (err 0) kernel: vboxdrv: Unknown symbol __x86_indirect_thunk_r14 (err 0) kernel: vboxdrv: Unknown symbol __x86_indirect_thunk_rbx (err 0) kernel: vboxdrv: Unknown symbol __x86_indirect_thunk_r13 (err 0) kernel: vboxdrv: Unknown symbol __x86_indirect_thunk_r10 (err 0) kernel: vboxdrv: Unknown symbol __x86_indirect_thunk_rcx (err 0) kernel: vboxdrv: Unknown symbol __x86_indirect_thunk_rsi (err 0) kernel: vboxdrv: Unknown symbol __x86_indirect_thunk_r9 (err 0) kernel: vboxdrv: Unknown symbol __x86_indirect_thunk_r12 (err 0) kernel: vboxdrv: Unknown symbol __x86_indirect_thunk_r8 (err 0) virtualbox[6834]: Loading VirtualBox kernel modules...modprobe vboxdrv failed. Please use 'dmesg' to find out why ... failed! virtualbox[6834]: failed! Bug#890479: pytz can't find any time zones 2018-02-14 Thread Evgeny Kapun Package: python3-tz Version: 2018.3-1 Severity: grave After upgrade to version 2018.3-1: >>> import pytz >>> pytz.all_timezones [] This is caused by this line in /usr/lib/python3/dist-packages/pytz/__init__.py: filename = os.path.join('usr','share' 'zoneinfo', *name_parts) So, instead of looking at /usr/share/zoneinfo/$time_zone_name, it is looking at (relative path) usr/sharezoneinfo/$time_zone_name (note the lack of comma after 'share', which leads 'share' and 'zoneinfo' to be merged into a single string literal). This code is horribly broken, but it worked because it fell back to using time zone files bundled with the package. Now that these files are not included anymore (see bug #884079), this package doesn't work! Bug#852146: Changing board size while game window is maximized results in clipped output 2017-11-22 Thread Evgeny Kapun Control: tags -1 fixed-upstream This is fixed upstream: https://git.tartarus.org/?p=simon/puzzles.git;a=commit;h=f03e8d30a038f740ea0bfe21474de5df69093893 Bug#560029: "new game" can't be undone 2017-11-22 Thread Evgeny Kapun Control: tags -1 fixed-upstream This is fixed upstream: https://git.tartarus.org/?p=simon/puzzles.git;a=commit;h=b9b73adb53b3ffb09a2e8c9682351bf892634470 Bug#878281: python3-numpy shouldn't depend on both Python 3.5 and Python 3.6 2017-11-13 Thread Evgeny Kapun That's how transitions for languages like python (and ruby, and others) are handled: 1) add support for the new version, and rebuild stuff to be able to run on multiple versions 2) switch the default version 3) drop support for the old version. You filed this bug while we were in the middle of the process. Since a couple of weeks ago support for the old version (3.5) was removed, a rebuild of numpy has been issued and now it only depends on python 3.6. My point is that even during such a transition, there is no need to require the user to have multiple versions of Python installed in order to be able to install the package. Even if python3-numpy is built to work on both python3.5 and python3.6, the user should be able to install python3-numpy even if only one of the Python versions is installed. Now that python3-numpy is built against python3.6 only, this is not relevant, of course. Closing. Bug#878281: python3-numpy shouldn't depend on both Python 3.5 and Python 3.6 2017-10-11 Thread Evgeny Kapun Package: python3-numpy Version: 1:1.13.1-1 Currently, package python3-numpy depends on packages python3.5 and python3.6. As a result, to install python3-numpy, it is necessary to install both Python 3.5 and Python 3.6. To use python3-numpy, just one version of Python is enough, and a dependence on package python3 is sufficient to make sure that Python 3.x is installed. Therefore, the dependences on packages python3.5 and python3.6 are superfluous and should be removed. Also, other Python library packages don't have such dependencies. Bug#876644: System tray icons are shown without transparency 2017-09-24 Thread Evgeny Kapun On 24.09.2017 16:58, Dmitry Shachnev wrote: Hi Evgeny! On Sun, Sep 24, 2017 at 01:22:56PM +0300, Evgeny Kapun wrote: When an application using Qt 5 has a system tray icon, areas of the icon that should be transparent are black instead. For me, this affects GoldenDict (after it was changed to use Qt 5 instead of Qt 4) and VLC. Please specify what desktop environment you are using, so that we can reproduce the bug. I can reproduce this on LXDE. You need the task bar to have white background and also set it to auto-hide. When launching an application, the task bar must be hidden, otherwise the icon will be displayed correctly. While this may be a bug in LXDE, for some reason it only affects applications which use Qt 5. Application which use Qt 4 or GTK are not affected. Bug#876644: System tray icons are shown without transparency 2017-09-24 Thread Evgeny Kapun Package: libqt5widgets5 Version: 5.9.1+dfsg-9 When an application using Qt 5 has a system tray icon, areas of the icon that should be transparent are black instead. For me, this affects GoldenDict (after it was changed to use Qt 5 instead of Qt 4) and VLC. Bug#876565: ImageMagick crashes (assertion failure) when opening a malformed image file 2017-09-23 Thread Evgeny Kapun Package: imagemagick-6.q16 Version: 8:6.9.7.4+dfsg-16 An image that causes the crash is attached. $ identify image.png identify: ../../magick/quantum.c:216: DestroyQuantumInfo: Assertion `quantum_info != (QuantumInfo *) NULL' failed. Aborted Bug#876563: Some icons are broken 2017-09-23 Thread Evgeny Kapun Package: keepassx Version: 2.0.3-1 Some icon files shipped with KeePassX are not valid image files, and therefore not displayed. I found these broken files: /usr/share/keepassx/icons/database/C08_Socket.png /usr/share/keepassx/icons/database/C39_History.png /usr/share/keepassx/icons/database/C35_KRFB.png /usr/share/keepassx/icons/database/C46_Help.png Probably, these were generated using some buggy program. They need to be replaced with valid image files. Bug#876545: src.zip is placed in a wrong directory 2017-09-23 Thread Evgeny Kapun Package: openjdk-9-source Version: 9~b181-4 The file src.zip is placed into the directory /usr/lib/jvm/openjdk-9/lib, but should be placed into the directory /usr/lib/jvm/openjdk-9. Or, the symlink /usr/lib/jvm/java-9-openjdk-amd64/src.zip should be changed to point to the correct file (currently, it is dangling). Bug#873254: classes.jsa is not removed on package uninstall 2017-08-25 Thread Evgeny Kapun Package: openjdk-9-jre-headless Version: 9~b181-4 File /usr/lib/jvm/java-9-openjdk-amd64/lib/server/classes.jsa is created by postinst script and not removed when the package is uninstalled. Bug#862917: Warzone 2100 3.2 campaign is buggy and unplayable. Debian should package version 3.1 until this is resolved 2017-05-19 Thread Evgeny Kapun Debian version is affected. Another possibility is to take script files from version 3.1 and use them with version 3.2, but that would require some patching. As to why the bugs are not reported here, it is possible that the users don't want to bother Debian maintainer with bugs that affect upstream as well. Bug#862973: Package Warzone 2100 videos 2017-05-19 Thread Evgeny Kapun Package: warzone2100 Version: 3.2.1-2 Severity: wishlist There are videos in Warzone 2100, which are not packaged in Debian. Currently, users who wish to have those videos need to download and install them manually, which is cumbersome. The purpose of Debian archive is to make it easy for users to install software. This is why I ask to package those videos for Debian. This way, it would be possible to install both the game and the videos with a single command. Bug#862917: Warzone 2100 3.2 campaign is buggy and unplayable. Debian should package version 3.1 until this is resolved 2017-05-18 Thread Evgeny Kapun Package: warzone2100 Version: 3.2.1-2 Severity: important Starting from version 3.2, campaign scripts in Warzone 2100 are being rewritten in JavaScript [1]. As a result, they now have lots of bugs (some examples: [2], [3], [4]), making the campaign more or less unplayable. Because the developers are not very active in fixing those bugs, and because the new version doesn't offer any significant advantages to players, I think that Debian should stick to version 3.1 until the situation improves. [1] https://forums.wz2100.net/viewtopic.php?f=35&t=11872 [2] https://developer.wz2100.net/ticket/4541 [3] https://developer.wz2100.net/ticket/4549 [4] https://developer.wz2100.net/ticket/4565 Bug#860420: Secrets of the Ancients campaign is not packaged 2017-04-16 Thread Evgeny Kapun Source: wesnoth-1.13 Version: 1:1.13.7-1 Secrets of the Ancients is a new mainline campaign added to Wesnoth in version 1.13.7 [1]. It needs to be included in a Debian package. [1] https://raw.githubusercontent.com/wesnoth/wesnoth/1.13.7/players_changelog Bug#857639: Generated README file is bad 2017-03-13 Thread Evgeny Kapun Package: python3-afl Version: 0.5.5-1 Package python3-afl includes a README file (located at /usr/share/doc/python3-afl/README), which is generated from README.rst. Because of the way it is generated, it is missing important parts (specifically, snippets of source code) and is therefore unusable. I suggest including README.rst verbatim, as it is human readable enough. Bug#855228: icedove -> thunderbird transition: /etc/icedove is not removed 2017-02-15 Thread Evgeny Kapun Package: thunderbird Version: 1:45.6.0-3 After upgrading from Icedove to Thunderbird, I found that /etc/icedove directory is not removed. Here is what is left there: $ ls -laR /etc/icedove /etc/icedove: total 20 drwxr-xr-x 3 root root 4096 Feb 15 18:09 . drwxr-xr-x 144 root root 12288 Feb 15 18:09 .. drwxr-xr-x 2 root root 4096 Sep 12 2011 profile /etc/icedove/profile: total 8 drwxr-xr-x 2 root root 4096 Sep 12 2011 . drwxr-xr-x 3 root root 4096 Feb 15 18:09 .. The /etc/icedove/profile directory is probably left by an older version of icedove package, and should be removed. Bug#853877: golang-1.7-doc doesn't provide godoc command 2017-02-01 Thread Evgeny Kapun Package: golang-1.7-doc Version: 1.7.4-1 The description of package golang-1.7-doc says: You can view the formatted documentation by running "godoc--http=:6060", and then visiting http://localhost:6060/doc/install.html. However, this package doesn't in fact provide "godoc" command. Bug#845555: lxpanel: battery monitor no longer working 2017-01-21 Thread Evgeny Kapun In version 0.9.3-1, the remaining time is shown correctly. There is still a minor glitch: if battery charge level is 100%, the remaining time is not shown. I think that this is due to this check [1]. I think that this check is wrong. I think the right check would be "lx_b->b->seconds >= 0" (since -1 is used to indicate that the value is not available). BTW, time to full charge is still not correct, but now the reason is that the formula (time=energy/power) doesn't work for charging. While during discharge, power stays roughly the same (assuming that workload doesn't change), during charge power drops significantly as the battery nears full charge. As a result, the time displayed is about three times smaller than the actual time it takes for the battery to fully charge. Still, the value can be used as a (very) rough estimate. [1] https://git.lxde.org/gitweb/?p=lxde/lxpanel.git;a=blob;f=plugins/batt/batt.c;h=988d9fdfb7ec9a01d1d692b8ea30e3e3a878b9a5;hb=9dbda5c15782596983ae61478c1612262633ae41#l164 Bug#852146: Changing board size while game window is maximized results in clipped output 2017-01-21 Thread Evgeny Kapun Package: sgt-puzzles Version: 20161228.7cae89f-1 In many games (such as Loopy, Palisade, Slant), it is possible to select different sizes of the game board (using Type menu). However, if this is done while game window is maximized, the result won't look right (usually, only the top level corner would be visible). Bug#845555: Time left not shown 2017-01-04 Thread Evgeny Kapun On 04.01.2017 22:37, Andriy Grytsenko wrote: Confirming, the fix is not complete. I wonder why it takes them so much time to implement such a simple calculation (they have the amount of energy remaining and the power consumption, dividing one by the other yields the remaining time). Actually, I could fix it long ago if it was reproducible in my setup. Could you provide more info, please, which meters are available and which are not? Or even patch is more than welcome. Thank you. Here is an example of what is shown in a tooltip: Battery 0: 97% charged, 0:00 left Energy full design: 56160 mWh Energy full: 40930 mWh Energy now: 39900 mWh Power now:12804 mW Current voltage: 12.178 V So, everything is correct except the "0:00 left" part. Also, if the remaining percentage, after rounding, is equal to 100%, remaining time is not shown at all, even if the battery is discharging (and the plugin is showing that it is discharging). Here is the listing of /sys/class/power_supply/BAT0: total 0 drwxr-xr-x 3 root root0 Jan 4 23:01 . drwxr-xr-x 3 root root0 Jan 4 23:01 .. -rw-r--r-- 1 root root 4096 Jan 4 23:01 alarm -r--r--r-- 1 root root 4096 Jan 4 23:01 capacity -r--r--r-- 1 root root 4096 Jan 4 23:01 capacity_level -r--r--r-- 1 root root 4096 Jan 4 23:01 cycle_count lrwxrwxrwx 1 root root0 Jan 4 23:01 device -> ../../../PNP0C0A:00 -r--r--r-- 1 root root 4096 Jan 4 23:01 energy_full -r--r--r-- 1 root root 4096 Jan 4 23:01 energy_full_design -r--r--r-- 1 root root 4096 Jan 4 23:01 energy_now -r--r--r-- 1 root root 4096 Jan 4 23:01 manufacturer -r--r--r-- 1 root root 4096 Jan 4 23:01 model_name drwxr-xr-x 2 root root0 Jan 4 23:01 power -r--r--r-- 1 root root 4096 Jan 4 23:01 power_now -r--r--r-- 1 root root 4096 Jan 4 23:01 present -r--r--r-- 1 root root 4096 Jan 4 23:01 serial_number -r--r--r-- 1 root root 4096 Jan 4 23:01 status lrwxrwxrwx 1 root root0 Jan 4 23:01 subsystem -> ../../../../../../../../../class/power_supply -r--r--r-- 1 root root 4096 Jan 4 23:01 technology -r--r--r-- 1 root root 4096 Jan 4 23:01 type -rw-r--r-- 1 root root 4096 Jan 4 23:01 uevent -r--r--r-- 1 root root 4096 Jan 4 23:01 voltage_min_design -r--r--r-- 1 root root 4096 Jan 4 23:01 voltage_now From strace, I see that the plugin tries to access some files that are missing here. Here is the contents of /sys/class/power_supply/BAT0/uevent: POWER_SUPPLY_NAME=BAT0 POWER_SUPPLY_STATUS=Discharging POWER_SUPPLY_PRESENT=1 POWER_SUPPLY_TECHNOLOGY=Li-ion POWER_SUPPLY_CYCLE_COUNT=0 POWER_SUPPLY_VOLTAGE_MIN_DESIGN=1080 POWER_SUPPLY_VOLTAGE_NOW=12097000 POWER_SUPPLY_POWER_NOW=12677000 POWER_SUPPLY_ENERGY_FULL_DESIGN=5616 POWER_SUPPLY_ENERGY_FULL=4093 POWER_SUPPLY_ENERGY_NOW=3851 POWER_SUPPLY_CAPACITY=94 POWER_SUPPLY_CAPACITY_LEVEL=Normal POWER_SUPPLY_MODEL_NAME=42T4678 POWER_SUPPLY_MANUFACTURER=Panasonic POWER_SUPPLY_SERIAL_NUMBER= 2210 Hope this helps. Bug#845555: Time left not shown 2017-01-04 Thread Evgeny Kapun Control: reopen -1 Confirming, the fix is not complete. I wonder why it takes them so much time to implement such a simple calculation (they have the amount of energy remaining and the power consumption, dividing one by the other yields the remaining time). Bug#845926: Cannot install package openbox-lxde-session: trying to overwrite '/etc/xdg/lxsession/LXDE/autostart', which is also in package lxde-common 0.99.2-1 2016-11-26 Thread Evgeny Kapun Control: reassign -1 lxde-common On 27.11.2016 03:52, Andriy Grytsenko wrote: I believe it's some dpkg error, just look at list of files in lxde-common package at https://packages.debian.org/sid/all/lxde-common/filelist: /etc/xdg/lxpanel/LXDE/config /etc/xdg/lxpanel/LXDE/panels/panel /etc/xdg/pcmanfm/LXDE/pcmanfm.conf /usr/share/doc/lxde-common/README.Debian /usr/share/doc/lxde-common/changelog.Debian.gz /usr/share/doc/lxde-common/changelog.gz /usr/share/doc/lxde-common/copyright /usr/share/lxde/images/logout-banner.png /usr/share/lxde/images/lxde-icon.png /usr/share/lxde/wallpapers/lxde_blue.jpg /usr/share/lxde/wallpapers/lxde_green.jpg /usr/share/lxde/wallpapers/lxde_red.jpg there is no /etc/xdg/lxsession/LXDE/autostart file there! I have no idea what was happened in your system. Actually, after further investigation, I think that this file is a conffile left from a previous version of lxde-common package. These files should be removed by a maintainer script [1]. Since the maintainer script for lxde-common package doesn't do this, this is a bug in that package. [1] https://wiki.debian.org/DpkgConffileHandling Bug#845926: Cannot install package openbox-lxde-session: trying to overwrite '/etc/xdg/lxsession/LXDE/autostart', which is also in package lxde-common 0.99.2-1 2016-11-26 Thread Evgeny Kapun Package: openbox-lxde-session Version: 0.99.2-1 Severity: grave When trying to install openbox-lxde-session package, dpkg fails with an error message: dpkg: error processing archive .../openbox-lxde-session_0.99.2-1_all.deb (--unpack): trying to overwrite '/etc/xdg/lxsession/LXDE/autostart', which is also in package lxde-common 0.99.2-1 Bug#843492: add bash completion for apt-mark 2016-11-06 Thread Evgeny Kapun Package: bash-completion Version: 1:2.1-4.3 Severity: wishlist There are already bash completions for apt-get and apt-cache commands. I propose adding completion for apt-mark command as well. Bug#842292: libnss3: re-enable SSLKEYLOGFILE support 2016-10-27 Thread Evgeny Kapun Package: libnss3 Version: 2:3.26-2 Severity: wishlist In previous versions of libnss, it was possible to use SSLKEYLOGFILE environment variable to save session keys to a file. Since version 3.24, this is disabled by default at compile time [1]. I think that SSLKEYLOGFILE support should be enabled for Debian builds of libnss, since otherwise users who need this functionality have to make their own builds of libnss. [1] https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.24_release_notes Bug#827517: [Pkg-mozext-maintainers] Bug#827517: Bug#827517: xul-ext-ublock-origin: Missing icons in uBlock's popup UI 2016-10-01 Thread Evgeny Kapun On 02.10.2016 07:41, Sean Whitton wrote: Thanks for this feedback. Unfortunately, installing an absolute symlink does not make the problem disappear for firefox-esr, contrary to various reports in this thread. That's because /usr/share/fonts-font-awesome/fonts/fontawesome-webfont.ttf is also a symlink. Symlink handling in Firefox is broken, but using an absolute symlink to the actual file (which is /usr/share/fonts/truetype/font-awesome/fontawesome-webfont.ttf) works. Bug#838787: libboost1.61-doc doesn't contain the actual documentation 2016-09-24 Thread Evgeny Kapun Package: libboost1.61-doc Version: 1.61.0+dfsg-2.1 The package libboost1.61-doc is supposed to include Boost documentation. It doesn't. All I can see in /usr/share/doc/libboost1.61-doc/HTML is a symlink to /usr/include/boost. There are some HTML files in /usr/share/doc/libboost1.61-doc/examples, but they only document the examples (also, most links in those files are broken). Bug#827517: [Pkg-mozext-maintainers] Bug#827517: xul-ext-ublock-origin: Missing icons in uBlock's popup UI 2016-09-15 Thread Evgeny Kapun This bug looks similar to bug #819900. That bug was caused by faulty handling of symlinks by Firefox, which Mozilla refuses to fix [1]. There is a simple workaround: use an absolute symlink instead of a relative one. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1286634 Bug#819900: Configuration page doesn't work on Firefox 45.0.1 2016-07-13 Thread Evgeny Kapun Control: tags -1 - upstream Looks like the problem is caused by the file being not found. This file is located at /usr/share/xul-ext/requestpolicy/content/settings/jquery.min.js, and it is a symbolic link. The real location of this file is /usr/share/javascript/jquery/jquery.min.js. However, Firefox accesses the file through the path /usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/rpcontin...@amo.requestpolicy.org/content/settings/jquery.min.js. Because jquery.min.js is a relative symlink, Firefox resolves it to /usr/share/mozilla/extensions/javascript/jquery/jquery.min.js, which doesn't exist. While I think that this is a bug in Firefox, a simple workaround is to use an absolute symlink. Bug#828705: Linux kernel update creates redundant symlinks 2016-06-27 Thread Evgeny Kapun On 27.06.2016 15:45, Ben Hutchings wrote: Control: tag -1 wontfix On Mon, 2016-06-27 at 15:20 +0300, Evgeny Kapun wrote: On 27.06.2016 15:03, Ben Hutchings wrote: Doesn't lilo fail if a file specified in its configuration is missing? Ben. LILO has an "optional" option which makes it skip an entry if either the kernel or the initrd file is missing (or is a broken link). That's a good point. I checked whether liloconfig would put the 'optional' keyword in /etc/lilo.conf, but the config file it generated didn't mention the symlinks at all. So I don't think it makes sense to assume that people use the 'optional' keyword. There are other boot loaders that I think will use the symlinks during package updates: elilo, palo and zipl. They all have similar configuration syntax to lilo, but it appears that elilo and palo do not support the 'optional' keyword. Although the 'old' symlinks will sometimes be redundant, I don't think this issue outweighs the inconvenience of a failed boot loader update. Ben. On the other hand, the current behavior (when both pairs of symlinks are always kept) was introduced not so long ago, so most existing setups should work with the old behavior. And I can't find anyone reporting the old behavior as a bug, so I think that the old behavior isn't actually any more problematic than the current one. Maybe add a config option to choose between the old and the current behavior? Also, if keeping all these symlinks is so important, then maintainer scripts should always prevent the only remaining installed kernel version from being removed, since there is no way to have valid symlinks after that. Now, such removal would proceed without any confirmation (unless that version happens to be the same as the one that is currently running), and all symlinks will be removed. Bug#828705: Linux kernel update creates redundant symlinks 2016-06-27 Thread Evgeny Kapun On 27.06.2016 15:03, Ben Hutchings wrote: Doesn't lilo fail if a file specified in its configuration is missing? Ben. LILO has an "optional" option which makes it skip an entry if either the kernel or the initrd file is missing (or is a broken link). Bug#828705: Linux kernel update creates redundant symlinks 2016-06-27 Thread Evgeny Kapun On 27.06.2016 11:51, Ben Hutchings wrote: Control: reassign -1 linux-base 4.3 Control: tag -1 moreinfo On Mon, 2016-06-27 at 03:59 +0300, Evgeny Kapun wrote: Package: linux-image-4.6.0-1-amd64 Version: 4.6.2-2 When updating the package linux-image-4.6.0-1-amd64 from version 4.6.2-1 to version 4.6.2-2, post-install script printed this: I: /vmlinuz.old is now a symlink to boot/vmlinuz-4.6.0-1-amd64 I: /initrd.img.old is now a symlink to boot/initrd.img-4.6.0-1-amd64 After that, both /{vmlinuz,initrd.img} and /{vmlinuz,initrd.img}.old point to the same kernel version, 4.6.0-1-amd64. Aren't these .old symlinks supposed to point to the previous version? If only one version is installed, both pairs of links will be pointed to it. Previously, one or both pairs could be left broken. Is there another version installed? Ben. No, there is only one version installed. Previously, there was only one pair of links in this case (the .old links were removed). I think that the old behavior is better because with the current behavior, bootloaders which use these symlinks (such as LILO) will create two menu entries for the same kernel version, which is confusing. When there is only one pair, such bootloaders will only create one entry. Bug#828705: Linux kernel update creates redundant symlinks 2016-06-26 Thread Evgeny Kapun Package: linux-image-4.6.0-1-amd64 Version: 4.6.2-2 When updating the package linux-image-4.6.0-1-amd64 from version 4.6.2-1 to version 4.6.2-2, post-install script printed this: I: /vmlinuz.old is now a symlink to boot/vmlinuz-4.6.0-1-amd64 I: /initrd.img.old is now a symlink to boot/initrd.img-4.6.0-1-amd64 After that, both /{vmlinuz,initrd.img} and /{vmlinuz,initrd.img}.old point to the same kernel version, 4.6.0-1-amd64. Aren't these .old symlinks supposed to point to the previous version? Bug#826059: java may crash when loading a class named java 2016-06-01 Thread Evgeny Kapun Package: openjdk-8-jre-headless Version: 8u91-b14-2 Tags: patch JVM may crash when trying to load a class named "java" in default package. How to reproduce: * Create a file named "java.java" with content "class java{}". * Compile it: `javac java.java'. * Try to run it: `java -cp "$PWD" java'. For some reason, running without `-cp' flag doesn't seem to trigger it. * It may not crash on the first try. It may be necessary to run it multiple times before it crashes. I attached a patch that should fix this problem. --- a/hotspot/src/share/vm/classfile/systemDictionary.cpp +++ b/hotspot/src/share/vm/classfile/systemDictionary.cpp @@ -1087,6 +1087,7 @@ if (!HAS_PENDING_EXCEPTION && !class_loader.is_null() && parsed_name != NULL && + parsed_name->utf8_length() >= strlen(pkg) && !strncmp((const char*)parsed_name->bytes(), pkg, strlen(pkg))) { // It is illegal to define classes in the "java." package from // JVM_DefineClass or jni_DefineClass unless you're the bootclassloader Bug#825022: man pages for *xattr syscalls are missing from manpages-dev 2016-05-22 Thread Evgeny Kapun Package: manpages-dev Version: 4.06-1 Linux man-pages project has pages about *xattr syscalls, like this [1]. However, they are not present in manpages-dev package for some reason. I think this is a bug. [1] http://man7.org/linux/man-pages/man2/getxattr.2.html Bug#800581: goldendict: CPU usage is more than expected 2016-05-16 Thread Evgeny Kapun From the official bug tracker [1], I found that such behavior can be caused by full-text search indexing. And what? As soon as I went to settings and disabled full-text search, CPU usage dropped to zero. Moreover, while dictionaries are being indexed for full-text search, there is a label at the bottom of the main window telling this. So, I think that this report should be closed. [1] https://github.com/goldendict/goldendict/issues/640 Bug#819900: Configuration page doesn't work on Firefox 45.0.1 2016-04-03 Thread Evgeny Kapun Package: xul-ext-requestpolicy Version: 1.0.0~beta11.1+dfsg-1 Severity: important On Firefox 45.0.1, the configuration page (about:requestpolicy) doesn't open. As a result, it is not possible to configure the extension. Bug#791982: New upstream games 2016-02-14 Thread Evgeny Kapun Any updates? Currently packaged version is more than 18 months old, which is probably old enough to update it. Bug#812110: KeePassX 0.4 and KeePassX 2.0 should be in different packages 2016-02-04 Thread Evgeny Kapun On 05.02.2016 00:13, Felix Geyer wrote: On 20.01.2016 19:53, Evgeny Kapun wrote: I think most tools support the .kdbx format by now so shipping just one version seems like the right choice to me. The problem is that if the same database is used on multiple machines, they must be all upgraded at the same time. With your approach, it is not be possible to use the same database on machines running, say, jessie and stretch. Unless the new version is backported to old Debian versions (at least jessie), those versions would have no native tools which support .kdbx format, and simultaneously upgrading multiple systems may not be possible. I'll upload 2.0.2 to jessie-backports once it reaches testing. Felix And still, if both versions have the same package name, it is not possible to have them installed simultaneously. Bug#812950: xul-ext-requestpolicy doesn't work in Iceweasel 44.0 2016-01-27 Thread Evgeny Kapun Package: xul-ext-requestpolicy Version: 1.0.0~beta10+dfsg-1 Severity: grave After I updated Iceweasel to version 44.0, RequestPolicy stopped working. Requests are not blocked and there is no toolbar button. It is still listed as enabled on about:addons, but it behaves as if it were not enabled. Bug#812143: Wide character in print at /usr/bin/ts line 126, <> line 1. 2016-01-22 Thread Evgeny Kapun On 22.01.2016 09:01, Nicolas Schier wrote: Dear Evgeny, I can get rid of the 'Wide character...' warning by adding the line use open ':locale'; (cp. attached patch). Could you please check whether this is sufficient for you? Unfortunately, the 'ts -r' does not work for ru_RU.*... Kind regards, Nicolas With this change, it will print a warning if the input is not valid UTF-8: $ echo $'\xff' | ./ts utf8 "\xFF" does not map to Unicode at ./ts line 95. янв 22 16:55:35 \xFF I don't know whether it's a serious problem, but I think that it's better to pass input data without attempting to decode it. Bug#812143: Wide character in print at /usr/bin/ts line 126, <> line 1. 2016-01-21 Thread Evgeny Kapun could you please supply your locale settings (the output of 'locale') and an example of a 'ts' output line? $ locale LANG=ru_RU.UTF-8 LANGUAGE= LC_CTYPE="ru_RU.UTF-8" LC_NUMERIC="ru_RU.UTF-8" LC_TIME="ru_RU.UTF-8" LC_COLLATE="ru_RU.UTF-8" LC_MONETARY="ru_RU.UTF-8" LC_MESSAGES="ru_RU.UTF-8" LC_PAPER="ru_RU.UTF-8" LC_NAME="ru_RU.UTF-8" LC_ADDRESS="ru_RU.UTF-8" LC_TELEPHONE="ru_RU.UTF-8" LC_MEASUREMENT="ru_RU.UTF-8" LC_IDENTIFICATION="ru_RU.UTF-8" LC_ALL= $ echo Example | ts Wide character in print at /usr/bin/ts line 126, <> line 1. янв 21 17:20:14 Example Bug#812143: Wide character in print at /usr/bin/ts line 126, <> line 1. 2016-01-20 Thread Evgeny Kapun Package: moreutils Version: 0.57-1 After I upgraded Perl to version 5.22, ts started printing a warning before every line, like this: Wide character in print at /usr/bin/ts line 126, <> line 1. This is annoying. Bug#812120: update-initramfs fails if busybox is not installed 2016-01-20 Thread Evgeny Kapun On 21.01.2016 01:16, Ben Hutchings wrote: Control: reassign -1 cryptsetup Control: forcemerge 783297 -1 On Thu, 2016-01-21 at 00:56 +0300, Evgeny Kapun wrote: On 20.01.2016 22:41, Ben Hutchings wrote: On Wed, 2016-01-20 at 22:21 +0300, Evgeny Kapun wrote: Package: initramfs-tools-core Version: 0.121 If I try to run update-initramfs while busybox is not installed, I get an error message: E: busybox is required but not installed E: /usr/share/initramfs-tools/hooks/busybox failed with return 1. This happens irrespective of the BUSYBOX setting in /etc/initramfs-tools/initramfs.conf. You have another package installed (maybe cryptsetup) that requires busybox to work in the initramfs. Try this: grep -r BUSYBOX /usr/share/initramfs-tools/conf-hooks.d Ben. Yes, I have cryptsetup installed, but this problem appeared only after upgrading initramfs-tools to version 0.121. This change is related to #783297. cryptsetup *requires* busybox in the initramfs. If you don't have an encrypted root or /usr then you can get away without it. Assuming that's the case, I'm reassigning this to cryptsetup as there is an existing request to separate out the initramfs support. Ben. Hmm... I have an encrypted root, and it works somehow without busybox. Bug#812120: update-initramfs fails if busybox is not installed 2016-01-20 Thread Evgeny Kapun On 20.01.2016 22:41, Ben Hutchings wrote: On Wed, 2016-01-20 at 22:21 +0300, Evgeny Kapun wrote: Package: initramfs-tools-core Version: 0.121 If I try to run update-initramfs while busybox is not installed, I get an error message: E: busybox is required but not installed E: /usr/share/initramfs-tools/hooks/busybox failed with return 1. This happens irrespective of the BUSYBOX setting in /etc/initramfs-tools/initramfs.conf. You have another package installed (maybe cryptsetup) that requires busybox to work in the initramfs. Try this: grep -r BUSYBOX /usr/share/initramfs-tools/conf-hooks.d Ben. Yes, I have cryptsetup installed, but this problem appeared only after upgrading initramfs-tools to version 0.121. Bug#812120: update-initramfs fails if busybox is not installed 2016-01-20 Thread Evgeny Kapun Package: initramfs-tools-core Version: 0.121 If I try to run update-initramfs while busybox is not installed, I get an error message: E: busybox is required but not installed E: /usr/share/initramfs-tools/hooks/busybox failed with return 1. This happens irrespective of the BUSYBOX setting in /etc/initramfs-tools/initramfs.conf. Bug#812110: KeePassX 0.4 and KeePassX 2.0 should be in different packages 2016-01-20 Thread Evgeny Kapun Package: keepassx KeePassX 2.0, the new upstream version, stores password databases in a format incompatible with KeePassX 0.4. As a result, some users may prefer to keep the old version for interoperability. However, because Debian package for KeePassX 2.0 uses the same name as KeePassX 0.4, it is not possible to install both version simultaneously. I think the right choice would have been to package KeePassX 2.0 under a different name (e.g. keepassx2) because it is so much different from KeePassX 0.4. Bug#807107: ssh: doesn't support SSH protocol version 1 2015-12-05 Thread Evgeny Kapun Package: openssh-client Version: 1:7.1p1-1 After the last update, ssh can't use SSH protocol version 1. Moreover, if "Protocol 1" option appears anywhere in ssh_config file, ssh will not work at all. Unfortunately, there are still SSH servers which don't support protocol version 2. Unfortunately, people who use these servers usually don't have administrative access so they can't upgrade them. I understand why support for such an old protocol is disabled by default, but why remove it completely? As a result, people who need to access these older servers will have to use alternative builds or even build SSH client manually. How to reproduce: $ ssh 217.112.42.93 Protocol major versions differ: 2 vs. 1 $ ssh -1 217.112.42.93 ssh1 is not supported Bug#804479: NumPy reference is broken 2015-11-08 Thread Evgeny Kapun Package: python-numpy-doc Version: 1:1.9.2-5 Severity: important Many of the pages in NumPy reference are missing most of the content, like this [1]. Look how this page is supposed to look like [2]. [1]: /usr/share/doc/python-numpy-doc/html/reference/routines.set.html [2]: https://docs.scipy.org/doc/numpy-1.9.2/reference/routines.set.html Bug#799123: Debug::pkgAcquire::Worker output is percent-encoded incorrectly 2015-10-19 Thread Evgeny Kapun The precent encoding is done on characters, not on bytes. That's not correct. On UTF-8 locales, each byte is encoded separately. I presume you are trying this on an amd64 machine, which has a signed char, so the valid range is from -128 (or -127) to 127 only. I am a bit at a lost here as I don't understand what the problem is… maybe you can give us an idea how and why you are trying to sent bytes instead of characters in our textinterface here? Well, I was just diagnosing a problem with APT downloads and enabled debug output, and in that output there were error messages (from strerror(3)) which were encoded such that each character was encoded into 18 characters, which is not very easy to read, like this: %ffd0%ff9e%ffd1%ff82%ffd0%ffba%ffd0%ffb0%ffd0%ffb7%ffd0%ffb0%ffd0%ffbd%ffd0%ffbe %ffd0%ffb2 %ffd0%ffb4%ffd0%ffbe%ffd1%ff81%ffd1%ff82%ffd1%ff83%ffd0%ffbf%ffd0%ffb5 And I thought that it would be a good idea if they were encoded in some more human-readable way, because I think that I shouldn't need a script just to decode debug output. Bug#802427: "async" and "await" keywords are not highlighted as such 2015-10-19 Thread Evgeny Kapun Package: python3.5-doc Version: 3.5.0-3 Severity: minor In Python 3.5, two new keywords were added: async and await. However, in the code examples in the documentation, they are not highlighted as keywords. Bug#800581: goldendict: CPU usage is more than expected 2015-10-13 Thread Evgeny Kapun Same for me. Here is a backtrace from the thread which is doing it: #0 0x77bcd3e8 in inflate () at /lib/x86_64-linux-gnu/libz.so.1 #1 0x77bd11d5 in uncompress () at /lib/x86_64-linux-gnu/libz.so.1 #2 0x00512c38 in BtreeIndexing::BtreeIndex::readNode(unsigned int, std::vector >&) () #3 0x00516c37 in BtreeIndexing::BtreeIndex::findArticleLinks(QVector*, QSet*, QSet*, QAtomicInt*) () #4 0x0066b0da in FtsHelpers::makeFTSIndex(BtreeIndexing::BtreeDictionary*, QAtomicInt&) () #5 0x005411b8 in () #6 0x0065f888 in FTS::Indexing::run() () #7 0x7059ee3a in () at /usr/lib/x86_64-linux-gnu/libQtCore.so.4 #8 0x705abe6c in () at /usr/lib/x86_64-linux-gnu/libQtCore.so.4 #9 0x7031c0a4 in start_thread (arg=0x7fffddd97700) at pthread_create.c:309 #10 0x7fffef7bf06d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Bug#801326: embedded web browser used to display cards is insecure 2015-10-08 Thread Evgeny Kapun Package: anki Version: 2.0.32+dfsg-1 Tags: security In Anki, cards [1] are formatted using HTML and displayed using a web browser control. That browser is not appropriately restricted, for example: * Script execution is permitted. * Arbitrary file: URLs can be accessed. * Arbitrary http: and https: URLs can be accessed. As a result, a malicious deck may, for example: * Call home any time it is used. * Exfiltrate local files, similar to CVE-2015-4495 [2]. * Take over vulnerable routers and other servers in the same LAN. To reproduce, insert this into a card template: click -> script execution. -> local file access. http://example.com/path/to/remote/file"/> -> remote file access. [1] http://ankisrs.net/docs/manual.html#basics [2] http://www.welivesecurity.com/2015/08/11/firefox-under-fire-anatomy-of-latest-0-day-attack/ Bug#799124: apt should print details about ignored errors 2015-09-15 Thread Evgeny Kapun Package: apt Version: 1.1~exp12 Severity: wishlist Sometimes, APT ignores errors. For example, if there is an error while downloading Packages.xz, APT may ignore it and try to download Packages.gz instead. Currently, it is not easy to obtain the error message for such errors, which makes debugging these problems more difficult. I think that APT should either show details about such errors by default or have an option to enable this. Bug#799123: Debug::pkgAcquire::Worker output is percent-encoded incorrectly 2015-09-15 Thread Evgeny Kapun Package: apt Version: 1.1~exp12 Severity: minor Debug::pkgAcquire::Worker option causes APT to produce debug output, some of which is percent-encoded. Bytes with values greater than or equal to 128 are encoded incorrectly: for example, the value 128 should be encoded as %80, but is actually encoded as %ff80. Bug#799121: local repository in non-world-readable directory doesn't work 2015-09-15 Thread Evgeny Kapun Package: apt Version: 1.1~exp12 I'm using APT with a local repository configured with a file: URI. Also, the directory containing the repository is not world-readable. This works fine with APT 1.0, but not with APT 1.1. I found that APT 1.1 runs some of its helper programs under a restricted _apt account, and they attempt to access repository files directly and fail. Specifically, when running `apt update`, debug logs indicate that `/usr/lib/apt/methods/xz` program attempts to access repository files and fails with EACCESS, probably as a result of running with limited privileges. Bug#674671: [icedove] Subject and message use different languages with spell checking 2015-07-20 Thread Evgeny Kapun On 20.07.2015 14:29, Carsten Schoenert wrote: On Mon, Jul 20, 2015 at 10:40:48AM +0300, Evgeny Kapun wrote: This issue is not gone. Steps to reproduce: 1. Create a new message. 2. Click on subject line text box. 3. Open context menu and select some spell checker language. 4. Click on message text area. 5. Open context menu and select a different spell checker language. 6. Click on subject line again. Now, both the subject and the message text are checked using the language selected in step 3, not step 5. This is the problem. I can't reproduce that. If you can select a spell checking language while you at step 3 you have something different than Icedove from the package. You have checked with a fresh profile or while working in safe mode? On all of my various installations I just can pick a language if I'm in the body of my new email. And of course it uses the last selected language. Ragards Carsten Ah, I forgot. You need to set message format to Plain Text Only. On step 3, you need to select the language using context menu. The toolbar button is disabled for some reason. See attached screenshot. Bug#674671: [icedove] Subject and message use different languages with spell checking 2015-07-20 Thread Evgeny Kapun This issue is not gone. Steps to reproduce: 1. Create a new message. 2. Click on subject line text box. 3. Open context menu and select some spell checker language. 4. Click on message text area. 5. Open context menu and select a different spell checker language. 6. Click on subject line again. Now, both the subject and the message text are checked using the language selected in step 3, not step 5. This is the problem. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Bug#789299: ImportError when trying to import gumbo 2015-06-19 Thread Evgeny Kapun Package: python3-gumbo Version: 0.10.1+dfsg-1 Severity: grave When trying to import gumbo, I get ImportError: >>> import gumbo Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3/dist-packages/gumbo/__init__.py", line 33, in from gumbo.gumboc import * File "/usr/lib/python3/dist-packages/gumbo/gumboc.py", line 29, in import gumboc_tags ImportError: No module named 'gumboc_tags' As a result, the package is unusable for me. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Bug#769706: florence: Crashes on openbox, as any buuton s pressed by mouse. 2015-05-16 Thread Evgeny Kapun I found that it crashes if at-spi-bus-launcher is not running. This may happen if package at-spi2-core is not installed. I think that florence should depend on at-spi2-core, as it doesn't seem to work without it. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Bug#776176: doc-rfc is outdated 2015-01-24 Thread Evgeny Kapun Package: doc-rfc Severity: wishlist The latest version of doc-rfc package is dated February 2012. It's almost three years since then, and more than 900 more RFCs has been published during this period. I think that this package needs an update, and that it should be updated at least every few months. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Bug#762889: apt-get should ignore cached data in case of invalid signature or hash mismatch 2014-09-25 Thread Evgeny Kapun > We verify the data before moving it to the final directory. If it is > there, it is either valid, or we have no key for it, or it is unsigned > (the latter two will disappear / be disabled at some point I think). > > We had some issues where that validation succeeded where it should not > (for example, on proxies returning a 200 OK page html page for every > request, because the parser would not have any signatures to check > then). They should be fixed now in newer releases I think. > > If you have a concrete issue, it would be great if you let us know, > but this bug is too generic. And re-verification is too expensive to > do anyway. The problem it is possible that cached data prevents `apt-get update` from working, even if currently all data on the server is valid. Another problem is that to make apt-get work again, it is necessary to manually clean /var/lib/apt/lists/partial. Also, some ISPs hijack all HTTP requests with 200 OK html page if you, for example, don't pay in time. After Internet access is restored, it is expected that running `apt-get update` would update package lists despite invalid data being returned previously, but this is not true. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Bug#762891: apt-get clean should also clean /var/lib/apt/lists/partial 2014-09-25 Thread Evgeny Kapun Package: apt Version: 1.0.9.1 Severity: wishlist Currently, `apt-get clean` only cleans /var/cache/apt/archives and /var/cache/apt/archives/partial. I think that it should also clean /var/lib/apt/lists/partial. Files located there are unverified, and having wrong files there may prevent apt-get from working (see bug #762889). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Bug#762889: apt-get should ignore cached data in case of invalid signature or hash mismatch 2014-09-25 Thread Evgeny Kapun Package: apt Version: 0.9.7.9+deb7u1 Tags: security When running `apt-get update`, I noticed that it couldn't update some of the lists because of invalid signatures (BADSIG). This happens most frequently when `Release` files don't correspond to `Release.gpg`. I thought that it might be some caching issue, so I removed all files from `/var/lib/apt/lists/partial`, and the problem disappeared. I think that this should happen automatically. Some wrong data might get cached for various reasons, and it's wrong if manual intervention is required to make apt-get work again. I think that in case of verification errors, such as bad signature, hash mismatch, expired Release file, etc, apt-get should download all files that may cause the error without using cached data. For example, in case of hash mismatch for a list file it should download both that file and the Release file with its hash, as the error can be caused by any of them. If Release file is re-downloaded, Release.gpg should be re-downloaded too, and the signature should be re-checked. Bottom line: wrong data in the (unverified) cache should not prevent apt-get from working. Marking this as a security issue because an attacker can poison cache just once to prevent unattended-upgrade from working. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Bug#762650: LXPanel doesn't reserve space on screen anymore 2014-09-23 Thread Evgeny Kapun Package: lxpanel Version: 0.7.1-1 LXPanel has an option to reserve space on screen for a panel, so that it is not used by maximized windows. After an update from version 0.7.0-1 to 0.7.1-1, this option stopped working. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Bug#760574: Access to Virtualbox should be limited to a group of users 2014-09-05 Thread Evgeny Kapun Package: virtualbox Version: 4.3.14-dfsg-1 Tags: security Virtualbox has a lot of code. Virtualbox has five setuid root binaries and four kernel modules. Virtualbox has a large attack surface. And yet any user can run Virtualbox. Not just real users, but also accounts used for running web applications and other potentially untrusted code. All of them may try to exploit Virtualbox to elevate their privileges or at least break system's networking (see bug #760569). There is already a vboxusers group, but it only controls access to USB devices. There should be a different group such that users outside that group can't run Virtualbox at all. They just shouldn't have a permission to execute Virtualbox binaries (at least those that are setuid root). They also shouldn't be able to access Virtualbox device nodes in any way. This way, even if Virtualbox has a privilege elevation flaw, most users wouldn't be able to make any use of it. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Bug#760569: Virtualbox lets any user mess with system's network configuration 2014-09-05 Thread Evgeny Kapun Package: virtualbox Version: 4.3.14-dfsg-1 Tags: security Virtualbox lets any local user create and configure network interfaces (vboxnet*), and also send and receive traffic through them. It also lets users bridge their VMs to other network interfaces. Normally, such operations are reserved for users with CAP_NET_ADMIN capability for a good reason. Such actions can be used to disrupt other users' communications, capture their network traffic and even perform MITM attacks against them. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Bug#760561: Output redirection lets local users overwrite any file writable by the caller 2014-09-05 Thread Evgeny Kapun Package: tribler Version: 6.2.0+git20130731.149555fa-2 Tags: security The script /usr/bin/tribler redirects its output to /tmp/$USER-tribler.log. If an attacker creates a symlink with this name pointing to one of the user's files, this file would be overwritten. The safe way to create a file in a world-writable directory like /tmp is mktemp(1). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Bug#756334: Configure script downloads files from the Internet 2014-07-28 Thread Evgeny Kapun Package: hoogle Version: 4.2.33-1+b1 Severity: critical Tags: security During configuration, hoogle postinst script attempts to download a file from the URL and subsequently unpack it. Moreover, the integrity of this file is not verified. This leads to the following possible attacks: * An attacker controlling the user's network connection may indefinitely delay the configuration of hoogle package by supplying data at a very low rate, even if package files themselves are available from local source. * The same attacker may supply bogus data instead of the file. This may not only lead to hoogle behaving in an erroneous manner, but may also lead to a full system compromise. For example, the archive may contain a malicious executable file marked SUID root, and local unprivileged user (who also participates in the attack) may run this file after it is extracted. The archive may also contain symlinks and device nodes, which can also be used for attack. * The same attacker may supply a very large file, filling the system partition and achieving denial of service. He may also supply a small file which becomes very large after un-gzipping. My suggestion is that downloading files in a secure manner is hard, and maintainer scripts probably shouldn't be doing it. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Bug#707006: [nik...@gmail.com: Live CD keys missing from key server] 2014-04-05 Thread Evgeny Kapun 06.04.2014 04:02, Jonathan McDowell wrote: > You're making an assumption that the key on the filesystem at > /usr/share/keyrings/debian-role-keys.gpg is the right one, which relies > on a whole extra chain of trust which I referred to above. If the keys are in /usr/share/keyrings/debian-role-keys.gpg, their authenticity is verified by APT during installation. If the user doesn't trust the verification performed by APT, he should not trust the system anyway. Therefore, the user can generally trust the keys in /usr/share/keyrings/debian-role-keys.gpg without any additional verification. By the way, GPG makes it rather nontrivial to securely verify a trust path from key A to key B without marking the key A as trusted. For example, there is no option to print a fingerprint of a key which is used to sign a given key, and matching keys by ID is not secure, since an attacker can forge a key with the same ID as that of a legitimate key. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Bug#707006: [nik...@gmail.com: Live CD keys missing from key server] 2014-04-02 Thread Evgeny Kapun 03.04.2014 00:50, Jonathan McDowell wrote: > Public keyservers aren't expected to provide verification of key > authenticity. The signatures on the keys themselves do that. The Debian > Live CD key is signed by Daniel, whose key is then signed by many other > DDs (and present in the debian-keyring package). If we pushed the Live > CD role key to the debian-keyring package we're still assuming the user > has access to a Debian box to install it and then also has a proper > trust path (presumably via the shasums on the APT package lists and then > the Debian archive signing key for those package lists) to that package. > If they're not using a Debian box to write the live CD then none of > these pieces help. > > In short putting the Live CD key in the debian-keyring package doesn't > demonstrably solve the problem of verifying a Live CD that I can tell. Putting Live CD key in the debian-keyring package makes verification MUCH easier. It would be just enough to run `gpgv --keyring /usr/share/keyrings/debian-role-keys.gpg /path/to/SHA1SUMS.sig', instead of having to find a signature made by the right key. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Bug#707006: [nik...@gmail.com: Live CD keys missing from key server] 2014-04-02 Thread Evgeny Kapun 02.04.2014 07:45, Jonathan McDowell wrote: > I don't actually think it's appropriate that this key lives in the > debian-role-keys keyring (and in general I think that keyring needs to > go away). The key should be present on the public keyserver network; > keyring.debian.org does not attempt to provide general keyserver > functionality and doesn't serve up the role keys anyway. Public keyserver network doesn't help in verifying key authenticity. Anyone can create a key with the same name as yours and put it on the public keyserver network. Having a key in debian-keyring package help users in establishing its legitimacy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Bug#741678: It is possible to use live user account to log in via SSH 2014-03-15 Thread Evgeny Kapun It is never mentioned in debian-live documentation that it is unsafe to connect to untrusted networks from a live system. If this is intended, it should be said clearly. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Bug#741678: It is possible to use live user account to log in via SSH 2014-03-15 Thread Evgeny Kapun I think that it is wrong if anyone on the same network can log into a live system and get full access to it. If a user connects, say, to a Wi-Fi network to download something, he doesn't expect his computer to become open to everyone. Currently, it is necessary to change the password before connecting to any untrusted networks, and most users won't do it, which makes them vulnerable. A possible solution is to disable password for default user (he is logged in automatically anyway), or to disable password authentication via SSH. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Bug#741678: It is possible to use live user account to log in via SSH 2014-03-15 Thread Evgeny Kapun Package: live-config Version: 4.0~alpha31-1 Severity: important Tags: security By default, live-config creates a user with known name (user) and password (live). In live images with included openssh-server, this means that anyone can log into a live system immediately once it connects to a network (which it tries to do during boot). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org 1 2 >

1 2 >

1 - 100 of 117 matches

Mail list logo