Dropbear

Category: debian

  • Debian WordPress 6.5

    Today I have updated the Debian WordPress packages to version 6.5.

    Not exactly sure what has changed, but they’re very excited over on the WordPress site about fonts and templates. I don’t think I’m selling it well, so hop over to the WordPress 6.5 Announcement for the real details.

  • Debian WordPress 6.4.1

    Debian WordPress 6.4.1

    The Debian WordPress package was updated tonight to version 6.4.1. Version 6.4 got missed before they updated to a minor update.

    The major change I can see is the introduction of a new theme called twentytwentyfour plus some easier, or more confusing, ways of writing posts. If you want more control on how they look, you’ll love it but if you just want to bang something out you won’t.

  • WordPress 5.2.4

    Hot on the heels of WordPress version 5.2.3 which fixed a bunch of stuff we have WordPress 5.2.4 with fixes for six security issues.

    There is a certain trick to matching up what the WordPress Blog thinks has been fixed and the changsets between the old version and the new. The curious thing is there were 6 changsets backported to older versions of WordPress, so you might think “six issues, six changesets, what’s the problem?”. The problem is that two of them fix the same thing (or one sort-of fixed it and the second really did) and another I couldn’t link to any vulnerability, BUT it was to do with directory traversal issue.

    The hardest part of maintaining the Debian WordPress packages is the backporting. Trying to link the changes to the bugs is next to impossible so I generally import all the ones they have in the specific major version and hope for the best. This isn’t ideal, but information about what the actual bugs are and how they are fixed is not forthcoming.

  • Backporting and git-buildpackage

    For working with Debian packages, one method of maintaining them is to put them in git and use git-buildpackage to build them right out of the git repository.  There are a few pitfalls with it, notably around if you forget to import the upstream you get this strange treeish related error which still throws me at first when I see it.

    Part of maintaining packages is to be able to fix security bugs in older versions of them that are found in stable and even sometimes old stable (jessie and wheezy respectively at the time of writing).  At first I used to do this outside git because to me there wasn’t a clear way of doing it within it.  This is not too satisfactory because it means you lose the benefits of using git in the first place, and for distributions you are more likely to need collaboration with, such as working with the security team or help with backporting.

    (more…)

  • WordPress 4.0.1 fixes for Debian stable

    Previously I posted a short article about the WordPress package for Debian and how that SID was getting the updated WordPress 4.0.1 which had some security fixes.

    The question a lot of people were asking was: What about stable (or Wheezy).  After way too much time due to other pressing issues, I have just uploaded the patched WordPress debian package for stable.  The fixed version has the catchy number of 3.6.1~deb7u5.  This package has all of the relevant patches that went in from WordPress 3.7.4 to 3.7.5 and there are even CVE IDs for this package (and 4.0.1 which all this stems from).

    (more…)

  • Linux Capabilities

    I was recently updating some code that uses fping. Initially it used exec() that was redirected to a temporary file but I changed it to use popen.  While it had been a while since I’ve done this sort of thing, I do recall there was an issue with running popen on setuid binary.  A later found it is mainly around setuid scripts which are very problematic and there are good reasons why you don’t do this.

    Anyhow, the program worked fine which surprised me. Was fping setuid root to get the raw socket?

    $ ls -l /usr/bin/fping
-rwxr-xr-x 1 root root 31464 May  6 21:42 /usr/bin/fping

    It wasn’t which at first all I thought “ok, so that’s why popen is happy”. The way that fping and other programs work is they bind to a raw socket. This socket sits below the normal type sockets such as the ones used for TCP and UDP and normal users cannot use them by default. So how did fping work it’s magic and get access to this socket? It used Capabilities.

     

    Previously getting privileged features had a big problem; it was an all or nothing thing. You want access to a raw socket? Sure, be setuid but that means you also could, for example, read any file on the system or set passwords. Capabilites provide a way of giving programs some better level of access, but not a blank cheque.

    The tool getcap is the way of determining what capabilities are found on a file. These capabilities are attributes on the file which, when the file is run, turn into capabilities or extra permissions. fping has the capability cap_net_raw+ep applied to it. This gives access to the RAW and PACKET sockets which is what fping needs. The +ep after the capability name means it is an Effective and Permitted capability, which describes what happens with child processes and dropping privileges.

    I hadn’t seen these Capabilities before. They are a nice way to give your programs the access they need, but limiting the risk of something going wrong and having a rouge program running as root.

    Related articles

  • No more dspam, now what?

    I was surprised at first to see that a long-standing bug in dspam had been fixed. Until that is, I realised it was from the Debian ftp masters and the reason the bug was closing was that dspam was being removed from the Debian archive.

     

    Damn!

     

    So, now what? What is a good replacement for dspam that is actually maintained? I don’t need anti-virus because mutt just ignores those sorts of things and besides youbankdetails.zip.exe doesn’t run too well on Debian. dspam basically used tokens to find common patterns of spam and ham, with you bouncing misses so it learnt from its mistakes. Already got postgrey running for greylisting so its really something that does the bayesan filtering.

     

    Some intial comments:

    • bogfilter looks interesting and seems the closest thing so far
    • cluebringer aka policyd seems like a policy and bld type of spam filter, not bayesan
    • I’ve heard crm114 is good but hard to use
    • spamassasin – I used to use this, not sure why I stopped

    There really is only me on the mailserver with a pretty light load so no need to worry about efficiencies.  Not sure if it matters but my MTA is postfix and I already use procmail for delivery.

     

     

  • WordPress 3.8 for Debian

    Well if you can read this then you know it’s working.  After way too many weeks, Debian will have WordPress version 3.8.  Thanks to Raphaël for his kind assistance and answering my questions about how it was built.  The upload is still gurgling along and will make it there in its own time. He said Handing over packages is hard, I’d agree but say taking over them is too.

    So, what does WordPress 3.8 look like?  From the “frontend” I didn’t really notice much.  The big changes, at least cosmetically, seem to be for the admin backend.  It just look slicker and cleaner.

    Hopefully Debian users find the update useful and I’ve not broken anything.  There’s always the BTS if there is.  I’ve deliberately tried to minimise the changes for this version to limit the breakage.

    Enhanced by Zemanta

  • Damn you, unworking r8168

    I really don’t know why ethernet device makers insist on making it hard for to use their products.  Ethernet has been around for many, many years; surely its not too much to ask for drivers that “just work”.

    And so that’s the problem I currently have with my new computer. It has an onboard Ethernet interface which uses a Realtek chip and that’s where the problems have been (with the exception of a power button that wriggled free, but that is also easy to fix).

    The device comes up as:

    03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 06)
    

    I’ve used:
    

      

    • The R8169 driver that comes with most of the Debian kernels
      • 

    • r8168-dkms driver
      • 

    • The 8168 driver from the realtek site
      • 

    

    and all of them don’t work.  It seems that the receive side works fine (I sometimes get a valid IPv6 address) but no packets are sent, even ifconfig eth0 shows zero transmitted packets.
    

    ethtool shows some of the setup, this is with the r8168 driver:
    

    driver: r8168
version: 8.037.00-NAPI
firmware-version:
bus-info: 0000:03:00.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: no
    

     
    

    Interestingly, if I use the r8169 driver in the kernel and try ifup etho then I do get an entry in the firmware-version spot.
    

    dmesg also shows that it finds the device.
    

    [    0.916487] r8168 Gigabit Ethernet driver 8.037.00-NAPI loaded
[    0.916667] r8168 0000:03:00.0: irq 72 for MSI/MSI-X
[    0.939129] r8168: This product is covered by one or more of the following patents: US6,570,884, US6,115,776, and US6,327,625.
[    0.939136] r8168  Copyright (C) 2013  Realtek NIC software team <[email protected]>
[   10.807066] r8168: eth0: link up
    

    So it all looks good, except it won’t send any packets.  Anyone got one of these devices and if so (and more importantly) how did you get it to work?
    

     
    

    
			
    
		
    
		
	
  • 
		
		
    
			
			
    pidof moving to procps
    
			
    pidof is a program that finds the PID of a named program. In some ways it is like a cut-down pgrep found in the procps package.  pidof currently sits in sysvinit-tools.
    

    There are plans to move all utilities that use the proc filesystem under one package which will make the maintenance of them simpler, which in effect means moving pidof from sysvinit-tools to procps. The short-term bump should make it better in the long term.
    

    Now as I wear two hats (Debian maintainer and procps upstream) there are two very important things I/we need to know.
    

      

    • If your Debian package depends on pidof being present, then we need to discuss dependencies. procps is generally installed on most systems but there might be corner cases. Possibly just depending on a specific version of procps will do it
      • 

    • If you, your Debian package or anything else (including other distributions) need the non-LSB options of pidof (ie they use -c -n or -m) then we (upstream) need to know about it. There are provisional plans not to support these options but they’re needed, or a subset is, then that could change.
      • 

    

    Debian developers can chime in on the debian-devel email list, or email myself. If its an upstream issue then either email me, or even better, the procps email list
    

    Enhanced by Zemanta