Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Packaging: Add placeholder packages #472

Closed
wants to merge 7 commits into from

Conversation

tiran
Copy link
Member

@tiran tiran commented Feb 16, 2017

The ipa and freeipa packages are placeholders to prevent PyPI squashing
attacks and reserve the names for future use. pip install ipa installs
ipaclient.

Signed-off-by: Christian Heimes cheimes@redhat.com

The new PR provides just the two placeholder packages from PR #379.

@MartinBasti MartinBasti self-assigned this Feb 17, 2017
@MartinBasti
Copy link
Contributor

Shouldn't we have build dependency on python[3]-wheel without it bdist_wheel target is not working

@MartinBasti
Copy link
Contributor

I'm not an expert about how PyPI is working, but shouldn't be there also placeholder packages for:

  • ipaserver
  • ipaplatform
  • ipatests

How about [free]ipa-server and friends, can a bad person use this for an attack when somebody uses pip install freeipa-server ?

configure.ac Outdated
@@ -577,6 +577,9 @@ AC_CONFIG_FILES([
ipaserver/Makefile
ipatests/Makefile
ipatests/man/Makefile
packaging/Makefile
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we rename this to wheel_packaging or pypi_packaging to be clear what is the purpose, because it is only for bdist_wheel

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure! how about just pypi?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

or pypi_placeholders

@tiran
Copy link
Member Author

tiran commented Feb 17, 2017

At the moment wheels are not required for RPM building. python-wheel is not available on RHEL, but I can work around it. Should the RPM spec file only contain dependencies for RPM packaging or also dependencies for general development and general packaging?

I can create placeholder modules for ipaserver, ipaplatform and ipatests, too. It's going to be a bit more tricky. Let's see...

@HonzaCholasta
Copy link
Contributor

Is this really the right thing to do? IMO it does not make much sense to have placeholders for every ipa* package, as it does not scale at all - nothing is preventing a potential attacker to register their own ipa* package, which will confuse PyPI users all the same and will prevent us to use that name ourselves in the future, should we want to.

@MartinBasti
Copy link
Contributor

We want to prevent others to have packages in PyPI with the same names as used for IPA. This is reasonable for protecting users to get attacker code from PyPI and rewrite working modules installed from rpms. In case that somebody install ipamodulefromhell we really cannot help this user

@tiran
Copy link
Member Author

tiran commented Feb 21, 2017

Yes, it is the right thing to do. You can trust in the expert with a decade of experience with Python packaging (formerly known as cheese shop).

@MartinBasti
Copy link
Contributor

I talked with Honza how to handle the build dependency for pypi, and we may to remove the commit that adds python-wheel or add new option to specfile that will install pypi related packages with_pypi or so.

Do you plan to have more dependencies related only to pypi?

@tiran
Copy link
Member Author

tiran commented Feb 21, 2017

You requsted a dependency in the first place :)

If you are going to add a special build or dependency flavor for PyPI packaging, please also add python[23]-twine. It's the uploader tool we are going to use to upload packages to PyPI.

@tiran
Copy link
Member Author

tiran commented Feb 22, 2017

OK, you got with_wheels in freeipa.spec.in now. with_wheels is more logical than with_pypi because wheels have more uses than just PyPI upload.

@MartinBasti
Copy link
Contributor

Thank you.

I see errors reported by pylint

************* Module ipaserver.install.installutils
ipaserver/install/installutils.py:1209: [E1101(no-member), store_version] Module 'ipaplatform' has no 'NAME' member)
ipaserver/install/installutils.py:1221: [E1101(no-member), check_version] Module 'ipaplatform' has no 'NAME' member)
ipaserver/install/installutils.py:1224: [E1101(no-member), check_version] Module 'ipaplatform' has no 'NAME' member)

@MartinBasti
Copy link
Contributor

LGTM, please rebase and I will test it.

@tiran
Copy link
Member Author

tiran commented Feb 22, 2017

@MartinBasti I have rebased the branch and added wheel + placeholder building to make check. The pylint violations have disappeared.

@MartinBasti
Copy link
Contributor

MartinBasti commented Feb 23, 2017

Is really needed to have this in make check? It makes build dependencies of wheel mandratory not optional

error: invalid command 'bdist_wheel'
make[5]: *** [bdist_wheel] Error 1
Makefile:591: recipe for target 'bdist_wheel' failed
make[5]: Leaving directory '/freeipa/rpmbuild/BUILD/freeipa-4.4.90.dev201702221837+git07cd377/pypi/freeipa'
Makefile:1192: recipe for target 'wheel_placeholder' failed
make[4]: *** [wheel_placeholder] Error 1
make[4]: *** Waiting for unfinished jobs....
usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
   or: setup.py --help [cmd1 cmd2 ...]
   or: setup.py --help-commands
   or: setup.py cmd --help

@tiran
Copy link
Member Author

tiran commented Feb 23, 2017

I'm open to suggestions here, but I like to have automatic validation of packaging.

@lslebodn
Copy link
Contributor

I agree with @MartinBasti it is not a unit test.
IMHO better approach is to test it in CI/travis/...

@tiran
Copy link
Member Author

tiran commented Feb 23, 2017

That's not the point here. We are arguing about a new build dependency (python-wheel).

@lslebodn
Copy link
Contributor

FYI: At the moment, make check run just C-based unit test and all of them are optional.
If required dependency is not found at configure time then test is not build/executed.

The reason is that required dependencies are not in some downstream distributions and IIRC python-wheel is not there either.

@pvoborni
Copy link
Member

Some distros like RHEL doesn't have python-wheel packaged. It can be disabled by downstream patch, but better would be to remove it or make it configurable.

@lslebodn
Copy link
Contributor

lslebodn commented Feb 23, 2017

NACK for downstream patch. The intention of build system refactoring was make packaging in downstream simpler.

@MartinBasti
Copy link
Contributor

@tiran I thought we agreed on having with_wheels in specfile and install dependencies only when you want to build wheel packages, what is not the case of RHEL. So what is the issue with python-wheel?

My only concern it to not run wheel build in make check

@tiran
Copy link
Member Author

tiran commented Feb 23, 2017

@MartinBasti I dropped the last commit. make check no longer checks wheel packages.

I'm going to open a new ticket for @martbab and ask him to add to add a proper test for wheel building to his awesome container magic.

@MartinBasti
Copy link
Contributor

The old pylint issue is back

************* Module ipaserver.install.installutils
ipaserver/install/installutils.py:1209: [E1101(no-member), store_version] Module 'ipaplatform' has no 'NAME' member)
ipaserver/install/installutils.py:1221: [E1101(no-member), check_version] Module 'ipaplatform' has no 'NAME' member)
ipaserver/install/installutils.py:1224: [E1101(no-member), check_version] Module 'ipaplatform' has no 'NAME' member)

pypi_packages: bdist_wheel wheel_placeholder
@echo -e "\n\nTo upload packages to PyPI, run:\n"
@echo -e " twine upload $(WHEELDISTDIR)/*-$(VERSION)-py2.py3-none-any.whl\n"

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason why top-level make need to be polluted with this new build targets?
They can be just in pypi/Makefile.am.
It will simplify IPA_PLACEHOLDERS; you will iterate over all SUBDIRS there.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, there are. If you look closely you will notice that the new target depends on bdist_wheel and wheel_placeholder and the placeholder parts creates wheels in dist/wheels. It doesn't maek sense to have the target just in pypi.

My first version iterated over subdirs in ./pypi. This doesn't work for ipacommands (next PR) because ipacommands must be built as sdist, not bdist_wheel.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can move all following make targets bdist_wheel wheel_bundle wheel_placeholder pypi_packages into pypi/Makefile.am
(including all dependencies.

The top level make file will be simpler. The same as before wheel/pypy effort.
And Makefile.am in sub directory pypy will be python only.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I respectfully decline your suggestion.

  • It's much more important to make package building and testing easy to use than to keep the top level Makefile simple.
  • The top level Makefile is the public interface. Sublevel makefiles are helpers. I don't like to have targets in sublevel makefiles that are not usable from the top level Makefile.
  • The targets are easily discoverable, .e.g. with make <tab>.

</bikeshedding>

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like to have bdist_wheel accessible from the top makefile too

Copy link
Contributor

@lslebodn lslebodn Feb 23, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that could be solved with

wheel_placeholder:
    $(MAKE) -C $(top_builddir)/pypi wheel_placeholder

It would make the main Makefile nicer+simpler but that's just nice to have

The main problem is not in this PR but in structure of directories in freeipa git.
There are not sub-directories for Python code/C-code/javascript code...
As a result of this there are many *.SUBDIR variables in top level makefile to workaround this directory structure.

I thought that moving some *.SUBDIR variables to pypi/Makefile.am would simplify it.

Sorry for a little noise.

@tiran
Copy link
Member Author

tiran commented Feb 23, 2017

Commit 1f8326a fixes an issue in Makefile.python.am. I think the issue caused ipaplatform and pypi/ipaplatform to cross streams.

The ipa and freeipa packages are placeholders to prevent PyPI squashing
attacks and reserve the names for future use. `pip install ipa` installs
ipaclient.

Signed-off-by: Christian Heimes <cheimes@redhat.com>
Signed-off-by: Christian Heimes <cheimes@redhat.com>
I also renamed the base directory to pypi and added a new build target
pypi_packages.

Signed-off-by: Christian Heimes <cheimes@redhat.com>
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Some calls to setup.py specified a build base, some did not. This can
lead to issues, e.g. build, clean and install are using different build
directories.

Signed-off-by: Christian Heimes <cheimes@redhat.com>
pylint gets confused by duplicated package names, e.g. ipaplatform and
pypi/ipaplatform.

Signed-off-by: Christian Heimes <cheimes@redhat.com>
@@ -20,7 +19,7 @@ all-local: $(top_builddir)/ipasetup.py
--build-base "$(abs_builddir)/build"

install-exec-local: $(top_builddir)/ipasetup.py
if [ "x$(pkginstall)" = "xtrue" ]; then \
if [ "x$(pkginstall)" != "xfalse" ]; then \
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I miss explanation why in commit message

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Default to pkginstall=true without duplicated definitions

automake was complaining about duplicated definition. I dropped pkginstall=true from Makefile.python.am and only set it in special Makefile.am

automake was complaining about duplicated definitions of pkginstall. It
was defined to true in Makefile.python.am only to be overriden in some
Makefile.am.

Now we assume that pkginstall is implicit true and only skip
installation when pkginstall is explicitly set to false.

Signed-off-by: Christian Heimes <cheimes@redhat.com>
@MartinBasti MartinBasti added the ack Pull Request approved, can be merged label Mar 1, 2017
@MartinBasti
Copy link
Contributor

master:

  • 2e78433 Packaging: Add placeholder packages
  • e2b9ea2 Add python-wheel as build requirement
  • acdd1f5 Add placeholders for ipaplatform, ipaserver and ipatests
  • b4c1bf1 Add with_wheels global to install wheel and PyPI packaging dependencies
  • ab9f42d Python build: use --build-base everywhere
  • 60cfacc pylint: ignore pypi placeholders
  • bc1f60b Default to pkginstall=true without duplicated definitions

@MartinBasti MartinBasti added the pushed Pull Request has already been pushed label Mar 2, 2017
@MartinBasti MartinBasti closed this Mar 2, 2017
@tiran tiran deleted the placeholder_packages branch March 15, 2017 10:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ack Pull Request approved, can be merged pushed Pull Request has already been pushed
Projects
None yet
5 participants