Hi, On 17:36 Tue 07 Feb , Alexander Kurtz wrote: > Package: puppet > Severity: critical > Tags: security > Justification: Potentially opens up a new security hole > > Hi! > > In the old days, users wanting the puppet binaries but not the puppet > daemon would install the puppet-common but not the puppet package [0]. > This changed when puppet 4.5 was uploaded to Debian, now the puppet > package contained the binaries and the puppet-agent package contained > the service [1]. This transition was done properly, as the new service > packages would not be installed by default. > > However, now somebody decided, that it's a good idea to drop the > puppet-agent package and move the service file back to the puppet > package [1]. This is bad, very, very bad. Here's why:
That somebody was me, apologies. Unfortunately the split to puppet/puppet-agent caused other issues (see #826730 and #827867) and we decided to revert it. > > 1. As of today, there is no apparently no package shipping only the > binaries but not the service files. > 2. I have quite a few systems where I occasionally run puppet manually, > but which should never run puppet automatically. > 3. Those systems began to look for a puppet master at the default > server address "puppet" recently as the new package version got > installed. > 4. As a result, anybody with control over DNS could have responded and > potentially taken over those systems. > > Please understand that your change made my and potentially other > people's system vulnerable without even telling them about it. I urge > you strongly to revert this change! When I moved things back to puppet, I failed to notice that the 3.x puppet agent behavior of starting the agent by default, but with a disable lock in place, was gone. I will fix this ASAP and file for an unblock. Regards, Apollon
