Hi, For those who may be interested I will leave this message here.
Mentioned package (dependency) manager is C++ Archive Network. https://cppan.org/ It generates CMakeLists.txt from specification files. It manages packages' dependencies, versions, different OSs (it's crossplatform from very beginning), handles crossplatform builds very easy (build will inherit your current project settings and autocrossplaform all deps). All builds are cached too - you build your dependency only once. Static/shared mt/md 32/64 deb/rel/... different toolchains (vc11, vc12,vc14, clangX.X, gcc-X) are handled and supported out of the box (with help of CMake). It also stores sources on its site, so they shouldn't be lost. And more to come. I've added a lot of popular packages. I didn't do much advertisement yet, so cppan is used only by a few people/projects at the moment. In my 'to add' list of big and very known projects: opencv (near future), qt (qt-lite?, ~ end of 2016). I'm adding small projects from time to time. Feel free to contact me here or privately. On 22 August 2016 at 20:52, Egor Pugin <egor.pu...@gmail.com> wrote: > Hi Chuck, > >> Is this intended to run on Linux? > > Yes. And thanks for the pointing out to SELinux. I'll add it to my checklist. > > --- > > The system is on very early stages now, so its parts are changing > rapidly and I'm able to consider different approaches to its > subsystems (including security). > But I probably confused all of you with the words 'package manager'. > It's the package manager only in the narrow sense. It's not trying to > be another apt, yum etc. Sorry that I didn't provide much details, but > the original topic is very precise and I think I'll return to it a bit > later when the functionality of the system will be in more stable > state. > > > On 22 August 2016 at 20:17, Chuck Atkins <chuck.atk...@kitware.com> wrote: >> Hi Egor, >> Is this intended to run on Linux? If so, I think you're FAR better off >> leveraging an existing security framework like SELinux, since it's actually >> designed from the ground up to enforce these types of controls. You could >> define a label that you place on the executables run by the package manager >> and then enforce whatever restrictions and controls you feel are >> appropriate. This will let you do things like block network access got the >> specific CMake executable used by the package system. It allows the CMake >> scripts to leverage all the available language and command features but >> deny, ant a system level, actions you deem unsafe or harmful. >> >> ---------- >> Chuck Atkins >> Staff R&D Engineer, Scientific Computing >> Kitware, Inc. >> >> >> On Sun, Aug 21, 2016 at 2:02 PM, Egor Pugin <egor.pu...@gmail.com> wrote: >>> >>> > What is the attack you want to stop? What are bad scripts and commands >>> > in this context? >>> >>> I wrote them in the first message. For example, >>> - any cmake commands that use COMMAND keyword (execute_process(COMMAND >>> ...), add_custom_{command|target}(...) etc. This will deny any user >>> scripts, programs (wget, curl, rm, ...). >>> - download commands (CMake's builtin curl) - they can fill the drives >>> with trash. >>> >>> > CMake runs lots of commands all the time. Most can be changed by a user, >>> > many are changed by the generator based on environment and whatnot. Any of >>> > these may be bad commands -- based on configuration. >>> >>> Yes, and it should deny only stuff above in small CMakeLists.txt part >>> that will be protected with some other commands or policies. >>> >>> > But if CMake gets a secure mode for your generator and if that is merged >>> > upstream, then I need to know about that when reading or writing >>> > CMakeLists.txt. >>> >>> For the moment I'm just asking about possibility of implementation of >>> these features. Any decision will go from CMake guys, not from me. So, >>> you shouldn't ask me about it. :) >>> >>> > Generated code is safe only as long as you very tightly control the >>> > environment CMake runs in. >>> >>> I don't care what is around, what is in user env. This is his >>> responsibility. I'm just worrying for my parts of CMake stuff. >>> >>> On 21 August 2016 at 20:43, Tobias Hunger <tobias.hun...@gmail.com> wrote: >>> > Hi Egor, >>> > >>> > Am 21.08.2016 12:34 schrieb "Egor Pugin" <egor.pu...@gmail.com>: >>> >> >>> >> > What are the attack scenarios you want to defend against? What should >>> >> > not be possible in your system that currently is in CMake? >>> >> >>> >> At least downloading or executing bad scripts and commands. >>> > >>> > What is the attack you want to stop? What are bad scripts and commands >>> > in >>> > this context? >>> > >>> > CMake runs lots of commands all the time. Most can be changed by a user, >>> > many are changed by the generator based on environment and whatnot. Any >>> > of >>> > these may be bad commands -- based on configuration. >>> > >>> > Downloading can be done using internal commands or by running e.g. wget >>> > or >>> > curl, both of which are pretty widely available on developer machines. >>> > >>> >> > That forces me to keep more state in my head when reading >>> >> > CMakeLists.txt >>> >> > files. >>> >> >>> >> CMake files are generated in my system. That's what I mean when I said >>> >> 'based on CMake'. >>> > >>> > Sure. But if CMake gets a secure mode for your generator and if that is >>> > merged upstream, then I need to know about that when reading or writing >>> > CMakeLists.txt. >>> > >>> >> It's like compiler compiler like yacc, bison, lex, flex. They are >>> >> producing output not for human readers, but for computer parsers. >>> >> And that's why generated code is safe and insertions from users are >>> >> not. >>> > >>> > Generated code is safe only as long as you very tightly control the >>> > environment CMake runs in. >>> > >>> >> Also in the most cases there's no any insertions at all, so it's rare >>> >> case. >>> > >>> > I'm sure you know what you are doing:) >>> > >>> > Best regards, >>> > Tobias >>> >>> >>> >>> -- >>> Egor Pugin >>> -- >>> >>> Powered by www.kitware.com >>> >>> Please keep messages on-topic and check the CMake FAQ at: >>> http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Kitware offers various services to support the CMake community. For more >>> information on each offering, please visit: >>> >>> CMake Support: http://cmake.org/cmake/help/support.html >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/cmake-developers >> >> > > > > -- > Egor Pugin -- Egor Pugin -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
