You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@whimsical.apache.org by sebb <se...@gmail.com> on 2022/01/14 00:44:02 UTC
Re: Broken: apache/whimsy#3682 (master - a875f5a)
Looks like the API for YAML.safe_load has changed. It now requires named
parameters.
I think *YAML*.safe_load(data, [Symbol]) now needs to be *YAML*.safe_load(data,
permitted_classes: [Symbol])
I have updated the code; hope it works ...
On Fri, 14 Jan 2022 at 00:12, Travis CI <bu...@travis-ci.com> wrote:
> apache
>
> /
>
> whimsy
>
> <https://app.travis-ci.com/github/apache/whimsy?utm_medium=notification&utm_source=email>
>
> [image: branch icon]master <https://github.com/apache/whimsy/tree/master>
> [image: build has failed]
> Build #3682 was broken
> <https://app.travis-ci.com/github/apache/whimsy/builds/244793181?utm_medium=notification&utm_source=email>
> [image: arrow to build time]
> [image: clock icon]9 mins and 57 secs
>
> [image: Sebb avatar]Sebb
> a875f5a CHANGESET →
> <https://github.com/apache/whimsy/compare/ee186940be85...a875f5a8004f>
>
> Make it more obvious user must be moderator
>
> Want to know about upcoming build environment updates?
>
> Would you like to stay up-to-date with the upcoming Travis CI build
> environment updates? We set up a mailing list for you!
> SIGN UP HERE <http://eepurl.com/9OCsP>
>
> [image: book icon]
>
> Documentation <https://docs.travis-ci.com/> about Travis CI
> Have any questions? We're here to help. <su...@travis-ci.com>
> Unsubscribe
> <https://app.travis-ci.com/account/preferences/unsubscribe?repository=16807422&utm_medium=notification&utm_source=email>
> from build emails from the apache/whimsy repository.
> To unsubscribe from *all* build emails, please update your settings
> <https://app.travis-ci.com/account/preferences/unsubscribe?utm_medium=notification&utm_source=email>.
>
> [image: black and white travis ci logo] <https://travis-ci.com>
>
> Travis CI GmbH, Rigaer Str. 8, 10427 Berlin, Germany | GF/CEO: Randy
> Jacops | Contact: contact@travis-ci.com | Amtsgericht Charlottenburg,
> Berlin, HRB 140133 B | Umsatzsteuer-ID gemäß §27 a Umsatzsteuergesetz:
> DE282002648
>
Re: Broken: apache/whimsy#3682 (master - a875f5a)
Posted by sebb <se...@gmail.com>.
On Sun, 16 Jan 2022 at 16:26, Sam Ruby <ru...@intertwingly.net> wrote:
>
> On Fri, Jan 14, 2022 at 10:43 AM sebb <se...@gmail.com> wrote:
>
> > On Fri, 14 Jan 2022 at 15:12, Sam Ruby <ru...@intertwingly.net> wrote:
> > >
> > > On Fri, Jan 14, 2022 at 9:52 AM sebb <se...@gmail.com> wrote:
> > > >
> > > > On Fri, 14 Jan 2022 at 14:04, Sam Ruby <ru...@intertwingly.net> wrote:
> > > > >
> > > > > On Fri, Jan 14, 2022 at 8:30 AM sebb <se...@gmail.com> wrote:
> > > > > >
> > > > > > I'm wondering whether we should pin major version numbers of Gems.
> > > > > >
> > > > > > Combined with a regular job to look for outdated Gems,
> > > > > > I think that would have given us advance warning.
> > > > >
> > > > > I gather that the gem in question that was updated was psych. We
> > > > > don't directly reference it in our Gemfile.
> > > >
> > > > It also affected yaml, but we don't seem to reference that either
> > >
> > > Yaml is part of the Ruby core runtime library. It does not provide a
> > > safe_load method. But all classes in Ruby are "open".
> > >
> > > Looking at Gemfile.lock for the board agenda tool, rdoc -- of all
> > > things -- pulls in psych. It specifies ">= 4.0.0".
> > >
> > > Here is the history for psych: https://rubygems.org/gems/psych
> > >
> > > > > There are two major strategies for dealing with dependencies:
> > > > >
> > > > > * The one we currently deploy aggressively pulls fixes, which has the
> > > > > benefit of being automatic, and ensures we are up to date
> > > > > (particularly with security fixes).
> > > >
> > > > But does it need to pull in changes to major versions?
> > > > Could we not pin the major versions but allow minor updates?
> > >
> > > It looks to me like this was released as a minor version.
> > >
> > > > > * The other is to check in Gemfile.lock files and only run in
> > > > > production what has been tested locally. This would request
> > > > > frequently updating Gemfile.lock files for each whimsy application
> > > > > locally and checking in the results.
> > > >
> > > > Is there any way to get advance notification of which gems have
> > updates?
> > > > And which have security implications?
> > > > That would be closer to the way that other ecosystems such as Java
> > work.
> > > >
> > > > Or at least if we had notification when there has been a change to a
> > > > major version of a Gem that would alert us to possible
> > > > incompatibilities.
> > >
> > > In summary, we are using an API that is not part of the documented
> > > interface for YAML, and might be considered "private" to psych.
> >
> > YAML says it is an alias for Psych, for which safe_load is documented:
> >
> >
> > https://ruby-doc.org/stdlib-2.5.9/libdoc/psych/rdoc/Psych.html#method-c-safe_load
> >
> > The above version is what we used originally
> >
> > It looks like it changed in
> >
> > https://ruby-doc.org/stdlib-2.6.1/libdoc/psych/rdoc/Psych.html#method-c-safe_load
> >
>
> Forgive me in advance for diving into semantics :-)
>
> From the definition of Semantic Versioning (https://semver.org/), the
> difference between 2.5.9 and 2.6.1 is a minor version, and differences in
> minor versions are supposed to be backwards compatible. Obviously this
> failed here. I've been burned by this enough that I don't place absolute
> trust in these distinctions.
Indeed
> Ruby and Node.js are examples where recent major versions didn't create
> major backwards compatibility issues.
> I've seen patch versions of gems take down whimsy applications.
>
> I'll repeat that it feels weird for us to start pinning versions of gems
> that aren't currently in our Gemfiles.
It may seem weird, but given the failures we have seen it may be the
sensible choice.
> I'll close with what an ideal situation would look like:
>
> * we check in Gemfile.lock files, and have our deployment do 'bundle
> install' instead of 'bundle update'.
> * we have a comprehensive test suite.
Easier said than done.
> * we have github actions that will update Gemfile.lock files upon
> successful execution of our tests.
I don't think bots are allowed to update ASF repos, but they could
send an email with details of what to do.
At present tests are only run on code changes, otherwise we might have
seen the breakage sooner.
An interim approach might be to ensure the tests run whenever Gem
versions are updated.
I don't know if that is possible.
> The end result is that we would automatically be kept up to date whenever a
> new version of any gem becomes available, as long as that change doesn't
> break something. And when there is breakage, we will be notified so that
> the problem can be addressed.
>
> - Sam Ruby
>
>
> > > It changed in a minor version in a way that broke our code.
> > >
> > > I don't know of any notification mechanism that would help with that
> > > combination.
> > >
> > > - Sam Ruby
> > >
> > > > >
> > > > > > On Fri, 14 Jan 2022 at 00:52, Sam Ruby <ru...@intertwingly.net>
> > wrote:
> > > > > > >
> > > > > > > I was debugging the same thing, and came to the same
> > conclusion. By
> > > > > > > the way this affects the roster tool as well as the board agenda.
> > > > > > >
> > > > > > > - Sam Ruby
> > > > > > >
> > > > > > > On Thu, Jan 13, 2022 at 7:44 PM sebb <se...@gmail.com> wrote:
> > > > > > > >
> > > > > > > > Looks like the API for YAML.safe_load has changed. It now
> > requires named
> > > > > > > > parameters.
> > > > > >
> > > > > > ...
> >
Re: Broken: apache/whimsy#3682 (master - a875f5a)
Posted by Sam Ruby <ru...@intertwingly.net>.
On Fri, Jan 14, 2022 at 10:43 AM sebb <se...@gmail.com> wrote:
> On Fri, 14 Jan 2022 at 15:12, Sam Ruby <ru...@intertwingly.net> wrote:
> >
> > On Fri, Jan 14, 2022 at 9:52 AM sebb <se...@gmail.com> wrote:
> > >
> > > On Fri, 14 Jan 2022 at 14:04, Sam Ruby <ru...@intertwingly.net> wrote:
> > > >
> > > > On Fri, Jan 14, 2022 at 8:30 AM sebb <se...@gmail.com> wrote:
> > > > >
> > > > > I'm wondering whether we should pin major version numbers of Gems.
> > > > >
> > > > > Combined with a regular job to look for outdated Gems,
> > > > > I think that would have given us advance warning.
> > > >
> > > > I gather that the gem in question that was updated was psych. We
> > > > don't directly reference it in our Gemfile.
> > >
> > > It also affected yaml, but we don't seem to reference that either
> >
> > Yaml is part of the Ruby core runtime library. It does not provide a
> > safe_load method. But all classes in Ruby are "open".
> >
> > Looking at Gemfile.lock for the board agenda tool, rdoc -- of all
> > things -- pulls in psych. It specifies ">= 4.0.0".
> >
> > Here is the history for psych: https://rubygems.org/gems/psych
> >
> > > > There are two major strategies for dealing with dependencies:
> > > >
> > > > * The one we currently deploy aggressively pulls fixes, which has the
> > > > benefit of being automatic, and ensures we are up to date
> > > > (particularly with security fixes).
> > >
> > > But does it need to pull in changes to major versions?
> > > Could we not pin the major versions but allow minor updates?
> >
> > It looks to me like this was released as a minor version.
> >
> > > > * The other is to check in Gemfile.lock files and only run in
> > > > production what has been tested locally. This would request
> > > > frequently updating Gemfile.lock files for each whimsy application
> > > > locally and checking in the results.
> > >
> > > Is there any way to get advance notification of which gems have
> updates?
> > > And which have security implications?
> > > That would be closer to the way that other ecosystems such as Java
> work.
> > >
> > > Or at least if we had notification when there has been a change to a
> > > major version of a Gem that would alert us to possible
> > > incompatibilities.
> >
> > In summary, we are using an API that is not part of the documented
> > interface for YAML, and might be considered "private" to psych.
>
> YAML says it is an alias for Psych, for which safe_load is documented:
>
>
> https://ruby-doc.org/stdlib-2.5.9/libdoc/psych/rdoc/Psych.html#method-c-safe_load
>
> The above version is what we used originally
>
> It looks like it changed in
>
> https://ruby-doc.org/stdlib-2.6.1/libdoc/psych/rdoc/Psych.html#method-c-safe_load
>
Forgive me in advance for diving into semantics :-)
From the definition of Semantic Versioning (https://semver.org/), the
difference between 2.5.9 and 2.6.1 is a minor version, and differences in
minor versions are supposed to be backwards compatible. Obviously this
failed here. I've been burned by this enough that I don't place absolute
trust in these distinctions.
Ruby and Node.js are examples where recent major versions didn't create
major backwards compatibility issues. I've seen patch versions of gems
take down whimsy applications.
I'll repeat that it feels weird for us to start pinning versions of gems
that aren't currently in our Gemfiles.
I'll close with what an ideal situation would look like:
* we check in Gemfile.lock files, and have our deployment do 'bundle
install' instead of 'bundle update'.
* we have a comprehensive test suite.
* we have github actions that will update Gemfile.lock files upon
successful execution of our tests.
The end result is that we would automatically be kept up to date whenever a
new version of any gem becomes available, as long as that change doesn't
break something. And when there is breakage, we will be notified so that
the problem can be addressed.
- Sam Ruby
> > It changed in a minor version in a way that broke our code.
> >
> > I don't know of any notification mechanism that would help with that
> > combination.
> >
> > - Sam Ruby
> >
> > > >
> > > > > On Fri, 14 Jan 2022 at 00:52, Sam Ruby <ru...@intertwingly.net>
> wrote:
> > > > > >
> > > > > > I was debugging the same thing, and came to the same
> conclusion. By
> > > > > > the way this affects the roster tool as well as the board agenda.
> > > > > >
> > > > > > - Sam Ruby
> > > > > >
> > > > > > On Thu, Jan 13, 2022 at 7:44 PM sebb <se...@gmail.com> wrote:
> > > > > > >
> > > > > > > Looks like the API for YAML.safe_load has changed. It now
> requires named
> > > > > > > parameters.
> > > > >
> > > > > ...
>
Re: Broken: apache/whimsy#3682 (master - a875f5a)
Posted by sebb <se...@gmail.com>.
On Fri, 14 Jan 2022 at 15:12, Sam Ruby <ru...@intertwingly.net> wrote:
>
> On Fri, Jan 14, 2022 at 9:52 AM sebb <se...@gmail.com> wrote:
> >
> > On Fri, 14 Jan 2022 at 14:04, Sam Ruby <ru...@intertwingly.net> wrote:
> > >
> > > On Fri, Jan 14, 2022 at 8:30 AM sebb <se...@gmail.com> wrote:
> > > >
> > > > I'm wondering whether we should pin major version numbers of Gems.
> > > >
> > > > Combined with a regular job to look for outdated Gems,
> > > > I think that would have given us advance warning.
> > >
> > > I gather that the gem in question that was updated was psych. We
> > > don't directly reference it in our Gemfile.
> >
> > It also affected yaml, but we don't seem to reference that either
>
> Yaml is part of the Ruby core runtime library. It does not provide a
> safe_load method. But all classes in Ruby are "open".
>
> Looking at Gemfile.lock for the board agenda tool, rdoc -- of all
> things -- pulls in psych. It specifies ">= 4.0.0".
>
> Here is the history for psych: https://rubygems.org/gems/psych
>
> > > There are two major strategies for dealing with dependencies:
> > >
> > > * The one we currently deploy aggressively pulls fixes, which has the
> > > benefit of being automatic, and ensures we are up to date
> > > (particularly with security fixes).
> >
> > But does it need to pull in changes to major versions?
> > Could we not pin the major versions but allow minor updates?
>
> It looks to me like this was released as a minor version.
>
> > > * The other is to check in Gemfile.lock files and only run in
> > > production what has been tested locally. This would request
> > > frequently updating Gemfile.lock files for each whimsy application
> > > locally and checking in the results.
> >
> > Is there any way to get advance notification of which gems have updates?
> > And which have security implications?
> > That would be closer to the way that other ecosystems such as Java work.
> >
> > Or at least if we had notification when there has been a change to a
> > major version of a Gem that would alert us to possible
> > incompatibilities.
>
> In summary, we are using an API that is not part of the documented
> interface for YAML, and might be considered "private" to psych.
YAML says it is an alias for Psych, for which safe_load is documented:
https://ruby-doc.org/stdlib-2.5.9/libdoc/psych/rdoc/Psych.html#method-c-safe_load
The above version is what we used originally
It looks like it changed in
https://ruby-doc.org/stdlib-2.6.1/libdoc/psych/rdoc/Psych.html#method-c-safe_load
> It changed in a minor version in a way that broke our code.
>
> I don't know of any notification mechanism that would help with that
> combination.
>
> - Sam Ruby
>
> > >
> > > > On Fri, 14 Jan 2022 at 00:52, Sam Ruby <ru...@intertwingly.net> wrote:
> > > > >
> > > > > I was debugging the same thing, and came to the same conclusion. By
> > > > > the way this affects the roster tool as well as the board agenda.
> > > > >
> > > > > - Sam Ruby
> > > > >
> > > > > On Thu, Jan 13, 2022 at 7:44 PM sebb <se...@gmail.com> wrote:
> > > > > >
> > > > > > Looks like the API for YAML.safe_load has changed. It now requires named
> > > > > > parameters.
> > > >
> > > > ...
Re: Broken: apache/whimsy#3682 (master - a875f5a)
Posted by Sam Ruby <ru...@intertwingly.net>.
On Fri, Jan 14, 2022 at 9:52 AM sebb <se...@gmail.com> wrote:
>
> On Fri, 14 Jan 2022 at 14:04, Sam Ruby <ru...@intertwingly.net> wrote:
> >
> > On Fri, Jan 14, 2022 at 8:30 AM sebb <se...@gmail.com> wrote:
> > >
> > > I'm wondering whether we should pin major version numbers of Gems.
> > >
> > > Combined with a regular job to look for outdated Gems,
> > > I think that would have given us advance warning.
> >
> > I gather that the gem in question that was updated was psych. We
> > don't directly reference it in our Gemfile.
>
> It also affected yaml, but we don't seem to reference that either
Yaml is part of the Ruby core runtime library. It does not provide a
safe_load method. But all classes in Ruby are "open".
Looking at Gemfile.lock for the board agenda tool, rdoc -- of all
things -- pulls in psych. It specifies ">= 4.0.0".
Here is the history for psych: https://rubygems.org/gems/psych
> > There are two major strategies for dealing with dependencies:
> >
> > * The one we currently deploy aggressively pulls fixes, which has the
> > benefit of being automatic, and ensures we are up to date
> > (particularly with security fixes).
>
> But does it need to pull in changes to major versions?
> Could we not pin the major versions but allow minor updates?
It looks to me like this was released as a minor version.
> > * The other is to check in Gemfile.lock files and only run in
> > production what has been tested locally. This would request
> > frequently updating Gemfile.lock files for each whimsy application
> > locally and checking in the results.
>
> Is there any way to get advance notification of which gems have updates?
> And which have security implications?
> That would be closer to the way that other ecosystems such as Java work.
>
> Or at least if we had notification when there has been a change to a
> major version of a Gem that would alert us to possible
> incompatibilities.
In summary, we are using an API that is not part of the documented
interface for YAML, and might be considered "private" to psych. It
changed in a minor version in a way that broke our code.
I don't know of any notification mechanism that would help with that
combination.
- Sam Ruby
> >
> > > On Fri, 14 Jan 2022 at 00:52, Sam Ruby <ru...@intertwingly.net> wrote:
> > > >
> > > > I was debugging the same thing, and came to the same conclusion. By
> > > > the way this affects the roster tool as well as the board agenda.
> > > >
> > > > - Sam Ruby
> > > >
> > > > On Thu, Jan 13, 2022 at 7:44 PM sebb <se...@gmail.com> wrote:
> > > > >
> > > > > Looks like the API for YAML.safe_load has changed. It now requires named
> > > > > parameters.
> > >
> > > ...
Re: Broken: apache/whimsy#3682 (master - a875f5a)
Posted by sebb <se...@gmail.com>.
On Fri, 14 Jan 2022 at 14:04, Sam Ruby <ru...@intertwingly.net> wrote:
>
> On Fri, Jan 14, 2022 at 8:30 AM sebb <se...@gmail.com> wrote:
> >
> > I'm wondering whether we should pin major version numbers of Gems.
> >
> > Combined with a regular job to look for outdated Gems,
> > I think that would have given us advance warning.
>
> I gather that the gem in question that was updated was psych. We
> don't directly reference it in our Gemfile.
It also affected yaml, but we don't seem to reference that either
> There are two major strategies for dealing with dependencies:
>
> * The one we currently deploy aggressively pulls fixes, which has the
> benefit of being automatic, and ensures we are up to date
> (particularly with security fixes).
But does it need to pull in changes to major versions?
Could we not pin the major versions but allow minor updates?
> * The other is to check in Gemfile.lock files and only run in
> production what has been tested locally. This would request
> frequently updating Gemfile.lock files for each whimsy application
> locally and checking in the results.
Is there any way to get advance notification of which gems have updates?
And which have security implications?
That would be closer to the way that other ecosystems such as Java work.
Or at least if we had notification when there has been a change to a
major version of a Gem that would alert us to possible
incompatibilities.
> - Sam Ruby
>
> > On Fri, 14 Jan 2022 at 00:52, Sam Ruby <ru...@intertwingly.net> wrote:
> > >
> > > I was debugging the same thing, and came to the same conclusion. By
> > > the way this affects the roster tool as well as the board agenda.
> > >
> > > - Sam Ruby
> > >
> > > On Thu, Jan 13, 2022 at 7:44 PM sebb <se...@gmail.com> wrote:
> > > >
> > > > Looks like the API for YAML.safe_load has changed. It now requires named
> > > > parameters.
> >
> > ...
Re: Broken: apache/whimsy#3682 (master - a875f5a)
Posted by Sam Ruby <ru...@intertwingly.net>.
On Fri, Jan 14, 2022 at 8:30 AM sebb <se...@gmail.com> wrote:
>
> I'm wondering whether we should pin major version numbers of Gems.
>
> Combined with a regular job to look for outdated Gems,
> I think that would have given us advance warning.
I gather that the gem in question that was updated was psych. We
don't directly reference it in our Gemfile.
There are two major strategies for dealing with dependencies:
* The one we currently deploy aggressively pulls fixes, which has the
benefit of being automatic, and ensures we are up to date
(particularly with security fixes).
* The other is to check in Gemfile.lock files and only run in
production what has been tested locally. This would request
frequently updating Gemfile.lock files for each whimsy application
locally and checking in the results.
- Sam Ruby
> On Fri, 14 Jan 2022 at 00:52, Sam Ruby <ru...@intertwingly.net> wrote:
> >
> > I was debugging the same thing, and came to the same conclusion. By
> > the way this affects the roster tool as well as the board agenda.
> >
> > - Sam Ruby
> >
> > On Thu, Jan 13, 2022 at 7:44 PM sebb <se...@gmail.com> wrote:
> > >
> > > Looks like the API for YAML.safe_load has changed. It now requires named
> > > parameters.
>
> ...
Re: Broken: apache/whimsy#3682 (master - a875f5a)
Posted by sebb <se...@gmail.com>.
I'm wondering whether we should pin major version numbers of Gems.
Combined with a regular job to look for outdated Gems,
I think that would have given us advance warning.
On Fri, 14 Jan 2022 at 00:52, Sam Ruby <ru...@intertwingly.net> wrote:
>
> I was debugging the same thing, and came to the same conclusion. By
> the way this affects the roster tool as well as the board agenda.
>
> - Sam Ruby
>
> On Thu, Jan 13, 2022 at 7:44 PM sebb <se...@gmail.com> wrote:
> >
> > Looks like the API for YAML.safe_load has changed. It now requires named
> > parameters.
...
Re: Broken: apache/whimsy#3682 (master - a875f5a)
Posted by Sam Ruby <ru...@intertwingly.net>.
I was debugging the same thing, and came to the same conclusion. By
the way this affects the roster tool as well as the board agenda.
- Sam Ruby
On Thu, Jan 13, 2022 at 7:44 PM sebb <se...@gmail.com> wrote:
>
> Looks like the API for YAML.safe_load has changed. It now requires named
> parameters.
>
> I think *YAML*.safe_load(data, [Symbol]) now needs to be *YAML*.safe_load(data,
> permitted_classes: [Symbol])
>
> I have updated the code; hope it works ...
>
> On Fri, 14 Jan 2022 at 00:12, Travis CI <bu...@travis-ci.com> wrote:
>
> > apache
> >
> > /
> >
> > whimsy
> >
> > <https://app.travis-ci.com/github/apache/whimsy?utm_medium=notification&utm_source=email>
> >
> > [image: branch icon]master <https://github.com/apache/whimsy/tree/master>
> > [image: build has failed]
> > Build #3682 was broken
> > <https://app.travis-ci.com/github/apache/whimsy/builds/244793181?utm_medium=notification&utm_source=email>
> > [image: arrow to build time]
> > [image: clock icon]9 mins and 57 secs
> >
> > [image: Sebb avatar]Sebb
> > a875f5a CHANGESET →
> > <https://github.com/apache/whimsy/compare/ee186940be85...a875f5a8004f>
> >
> > Make it more obvious user must be moderator
> >
> > Want to know about upcoming build environment updates?
> >
> > Would you like to stay up-to-date with the upcoming Travis CI build
> > environment updates? We set up a mailing list for you!
> > SIGN UP HERE <http://eepurl.com/9OCsP>
> >
> > [image: book icon]
> >
> > Documentation <https://docs.travis-ci.com/> about Travis CI
> > Have any questions? We're here to help. <su...@travis-ci.com>
> > Unsubscribe
> > <https://app.travis-ci.com/account/preferences/unsubscribe?repository=16807422&utm_medium=notification&utm_source=email>
> > from build emails from the apache/whimsy repository.
> > To unsubscribe from *all* build emails, please update your settings
> > <https://app.travis-ci.com/account/preferences/unsubscribe?utm_medium=notification&utm_source=email>.
> >
> > [image: black and white travis ci logo] <https://travis-ci.com>
> >
> > Travis CI GmbH, Rigaer Str. 8, 10427 Berlin, Germany | GF/CEO: Randy
> > Jacops | Contact: contact@travis-ci.com | Amtsgericht Charlottenburg,
> > Berlin, HRB 140133 B | Umsatzsteuer-ID gemäß §27 a Umsatzsteuergesetz:
> > DE282002648
> >