Alerts This Week
Warning Icon 1 659
Alerts This Week
Warning Icon 1 659

Stay Ahead With Linux Security News

Filter Icon Refine news
X Clear Filters
X Clear Filters
View More

Get the latest News and Insights

Get the latest Linux and open source security news straight to your inbox.

Community Poll

What got you started with Linux?

No answer selected. Please try again.
Please select either existing option or enter your own, however not both.
Please select minimum {0} answer(s).
Please select maximum {0} answer(s).
/main-polls/150-what-got-you-started-with-linux?task=poll.vote&format=json
150
radio
0
[{"id":483,"title":"Self-taught through trial and error","votes":545,"type":"x","order":1,"pct":78.42,"resources":[]},{"id":484,"title":"Formal training or courses","votes":30,"type":"x","order":2,"pct":4.32,"resources":[]},{"id":485,"title":"A job that required it","votes":34,"type":"x","order":3,"pct":4.89,"resources":[]},{"id":486,"title":"Other","votes":86,"type":"x","order":4,"pct":12.37,"resources":[]}] ["#ff5b00","#4ac0f2","#b80028","#eef66c","#60bb22","#b96a9a","#62c2cc"] ["rgba(255,91,0,0.7)","rgba(74,192,242,0.7)","rgba(184,0,40,0.7)","rgba(238,246,108,0.7)","rgba(96,187,34,0.7)","rgba(185,106,154,0.7)","rgba(98,194,204,0.7)"] 350
bottom 200
Loading...

Explore Latest Linux Security news

We found 2 articles for you...
78

Transforming Startup Operations with Linux and Open Source Solutions

If you're building a startup, you know the early days can feel like digital whiplash. One minute, you're hacking tools together to meet a launch deadline; the next, you're drowning in duct-taped systems and wondering why nothing scales. It’s exciting. It’s messy. And it's normal. . The Startup Stack Ritual: Build, Secure, Scale Startups often begin with messy tech setups due to speed and limited resources, a normal part of early growth. Open-source tools and Linux can offer cost-effective solutions during this chaotic phase, providing flexibility without the burden of licensing fees. Streamlining begins when startups make intentional decisions and hire experts to help with complex areas like infrastructure and security. Leveraging the expertise within the open-source community and integrating Linux can address these complexities more efficiently and securely. This is particularly true when making foundational decisions, like whether to go with Podman vs Docker — a choice many developers face when setting up containerized environments. Building scalable systems means choosing flexible, modular tools and embedding structure and security early in the process. Startups can create scalable, modular systems from the ground up by adopting Linux and open-source technologies like Kubernetes and Docker , ensuring security is built into the architecture. In the debate of Kubernetes vs Docker , it's not about which tool is better universally, but which one aligns best with your infrastructure goals — Kubernetes excels at orchestration while Docker handles packaging and deployment. The smartest shifts are often small — from better tool selection to outside support — and build momentum toward long-term clarity and growth. For example, understanding the trade-offs in Docker Swarm vs Kubernetes can be crucial in early architectural decisions; Docker Swarm might be simpler to get started with, but Kubernetes offers more advanced features for long-term scalability. Byincorporating Linux and open-source tools, startups can make incremental yet significant improvements that enhance their tech stack's stability and scalability, driving long-term success. But here’s the thing—every successful startup eventually hits a turning point where tech chaos becomes a serious roadblock. That moment when improvisation turns into inefficiency and growth starts tripping over its infrastructure. The good news? That turning point is also the gateway to a brighter, more sustainable future. In this post, we’re breaking down how savvy startups take control of their tech. We’ll examine why chaos happens, what changes when the right partners step in, and how clarity becomes the new competitive edge. If Slack threads, spreadsheets, and good intentions have held your team together, you're in the right place. Why Tech Chaos Happens in Startups Let’s be honest—no startup sets out to build a mess. But when speed is the game's name, things get creative. Founders are juggling products, pitch decks, user feedback, and the ever-present pressure to deliver. The Minimum Viable Product mindset means building just enough to get out the door, which often means cutting corners on structure and scale. It starts with a shared Google Drive, a few no-code tools, and maybe an ad hoc database running on someone’s server. You plug holes as they come up. You patch bugs instead of solving root causes. Everything’s working — until it’s not. This mess isn't a sign of failure; it’s a rite of passage. The early chaos can be a sign that your product is gaining traction. But the real inflection point comes when your tech foundation strains under the weight of success. That’s when it’s time to think beyond the MVP mindset and start building systems that grow with you. Turning the Corner With the Right Support So, how do you go from scattered to streamlined? The most innovative startups don’t try to solve everything in-house—they get help. Whether it’s securing theirinfrastructure or establishing long-term systems, they find partners who specialize in bringing order to chaos. This is where working with experienced providers becomes a game-changer. Instead of spending months building internal protocols from scratch, founders can lean on professionals who’ve seen every vulnerability in the book. In a world where a single breach can tank user trust overnight, leaving security as an afterthought isn’t an option. Startups that prioritize clarity understand this. They know that hiring help isn’t a cost; it’s a growth strategy. By delegating critical areas like security, they free up mental bandwidth to focus on what matters: building great products. That shift—from doing everything yourself to building with trusted support—is the first real sign that a startup is leveling up. Integrating Linux for Cost-Effective Scalability As with many startup decisions, an operating system is critical. Linux, an open-source operating system, offers startups a robust, secure, and cost-effective solution. Furthermore, its open-source nature means they can adapt it specifically for their own needs without incurring expensive license fees from proprietary software vendors. This is particularly important when scaling infrastructure dynamically as user bases expand. Linux's modular architecture enables startups to install only those components necessary for maximum resource use and performance, optimizing resource usage and performance. For example, if a team wants to install Docker on Ubuntu to begin containerization, Linux distributions like Ubuntu offer a smooth and supported experience. It’s often considered the best Linux distro for developers due to its large community, frequent updates, and extensive package support. Scalability also means running applications on either one server or across thousands of nodes; Linux handles it efficiently regardless of load. Plus, its large community provides knowledge, plugins, and support, helping startups overcomechallenges more rapidly. Integrating Linux from day one sets businesses up for an environment in which their technology infrastructure can grow organically with their success. Utilizing Open Source Tools for Agile Development Open-source solutions offer startups various invaluable tools and software for managing their tech setups, from development frameworks to project management tools such as Git, Jenkins, and Kubernetes. These tools make product creation, testing, and deployment more cost-effective without prohibitive proprietary license costs. Undertaking projects using open source allows startups to take advantage of contributions and innovations from an international community of developers. By adopting top-of-the-line open-source tools, they can maintain high levels of agility. Kubernetes , for instance, can effortlessly manage containerized applications. — a major plus in the Kubernetes vs Docker discussion. While Docker packages the application, Kubernetes takes care of deployment and scaling, offering a powerful one-two punch for startups needing speed and control. Similarly, understanding the nuances of Docker Swarm vs Kubernetes can help teams choose the orchestration tool that matches their growth stage. Docker Swarm is easier to set up, making it attractive for newer teams, while Kubernetes offers more advanced features for complex deployments. And for those exploring alternatives, comparing Podman vs Docker might lead to choosing Podman for its rootless capabilities and tighter security model. Open-source tools promote an environment of continuous improvement and collaboration among tech community members. They are frequently updated in response to community feedback, enabling startups to utilize cutting-edge technologies and security features. Businesses should see adopting open-source technology as an option and a strategic advantage supporting rapid growth and innovation dynamics. Building Scalable, Secure Tech From the Ground Up Once a startup decides to movepast the chaos, the next step is all about intention. That means ditching temporary hacks in favor of tech choices built to last. And no, you don’t need to hire a dozen engineers or overhaul everything at once — you need to start thinking like a company that will stick around. Smart startups begin by designing systems with scale in mind. That often means shifting to flexible and cost-efficient cloud-based infrastructure. Companies should prioritize modularity, choosing tools and platforms they can swap out or upgrade without shutting down the whole operation. This essentially future-proofs their stack piece by piece. And here’s the actual power move: baking in security from day one. Not tacked on at the end. Not handled only after a scare. But it is a core pillar of how your systems work. That can be as simple as implementing role-based access or setting up automated compliance alerts. It’s about embedding trust into your tech before things go sideways. Startups prioritizing scale and safety early on are in a much better position when opportunity knocks. Whether it’s investor due diligence, enterprise client demands, or international expansion, clarity in your systems gives you the confidence to say “yes” faster. Real Startup Moves That Make a Difference Let’s ground this in reality. What does it look like when startups take control of their tech mess? It’s not always about massive reboots — sometimes, the smallest shifts have the biggest impact. Take the founder, who managed customer data in six different spreadsheets. They saved hours each week by centralizing everything into a simple CRM, connecting it to their product analytics, and finally understanding their top users. The dev team is constantly putting out fires because they patched together their backend over the weekend. They brought in a freelance architect for one sprint, cleaned up their codebase, and finally got their nights and weekends back. Then there’s the startup that went from handling securitymanually to using automated scanning tools and partnering with a third-party service for monitoring. What used to be an anxiety-inducing mystery became a streamlined process that they didn’t have to think about every day. None of these changes were flashy. But each one helped transform a chaotic setup into something cleaner, clearer, and more powerful. That’s the real story behind “handling tech” — it’s not about perfection. It’s about making one smart move at a time and watching the compound effect take hold. Lessons Learned and What Comes Next There’s a simple truth about tech in startups: it will never be perfect. But perfection isn’t the goal — progress is. What separates high-growth startups from the rest isn’t the size of their engineering team or the fanciness of their stack. It’s their willingness to step back, assess what’s working (and what’s not), and make strategic upgrades along the way. One of the founders' biggest lessons is that clarity is an ongoing process. Your team grows, your users grow, and your needs evolve. The tools that worked for a scrappy five-person crew might buckle under a team of fifty. That’s okay. The key is building in moments to pause and reassess before things get out of control. Startups that thrive tend to have one thing in common: they know what not to build. They’re not afraid to lean on experts, outsource wisely, and automate wherever possible. It’s not about doing less — it’s about doing the right things with focus and intention. If your systems feel messy right now, you’re not behind — you’re just in the middle of the story. The shift to clarity doesn’t happen overnight but starts with one decision. Whether cleaning up your tech stack, getting help from the right people, or setting your team up for long-term scale, you don’t need a complete overhaul to make progress. You just need to start. Keep Learning About How Startups Win with Linux and Open Source Tools Tech chaos is almost a rite ofpassage in the startup world, but it’s not permanent. It’s a phase, and like all phases, it passes. The startups that rise above it aren’t necessarily the ones with the most money or the flashiest apps. They’re the ones who figure out how to turn mess into momentum. Startups can transform their work by intentionally prioritizing structure and knowing when to seek outside help. Clarity doesn’t mean everything runs perfectly — it means you know where things stand, and you can build with confidence. So, if you’re in the thick of the mess, don’t panic. You’re not alone. And you’re not stuck. Every step toward structure, no matter how small, is a move toward growth. You’ve got this. . Emerging companies are utilizing Linux and open-source tools to optimize operations, boost security, and accelerate expansion while minimizing expenses.. startups, Linux tools, open source technology. . Yasmin Ouakani

Calendar 2 Apr 03, 2025 User Avatar Yasmin Ouakani Vendors/Products
77

Benefits of Cloud Linux for E-Commerce: Security and Scalability Insights

Online stores are an essential part of the modern economy. Their stability, speed, and security directly affect a business's success. However, owners of online stores often have questions about the appropriate operating system. This is understandable, as they want modern solutions and high-quality service. . Among the many options, cloud Linux can be called the ideal solution. This operating system provides many advantages, especially for those working with e-commerce . If you want a suitable alternative, dedicated server hosting will be your faithful assistant. Many modern services offer access to safe and reliable equipment, enabling you to transform your business and succeed digitally. Benefits of Using Cloud Linux for Online Stores Cloud Linux has many advantages. It can make online store management more controlled and increase efficiency while strengthening eCommerce Security Stability and Fault Tolerance : Cloud technologies ensure continuous system operation, which is critical for sites with high loads. Powerful Protection : Cloud Linux provides strong security against external threats like viruses or hacking attempts . Scalability : It allows you to quickly scale your project as traffic grows without affecting the system's stability. Data Optimization : Cloud Linux is designed to handle large amounts of data efficiently, improving request processing speed and site loading time. Resource Management : Easily control the server's memory, processor, and other capabilities to distribute resources effectively. Such features are how the operating system Cloud Linux has many advantages. They are essential for the successful operation and growth of your business. Flexibility and Scalability in Cloud Linux An online store must function effectively so customers can comfortably use its offers. When pages load quickly, visitors do not have to wait long. As a result, they are happy and will visit the site repeatedly. If you want youronline store to operate exactly like this, you must worry about fast scalability and adaptability to changing market conditions. Cloud Linux perfectly copes with this task, offering high flexibility. You can add or remove resources quickly, and this is very important. This way, it’s possible to maintain your online store at the required level of performance. You will not be afraid of seasonal fluctuations in traffic. This is an excellent option for small businesses since, as they grow, you can easily switch to more powerful servers. Compare two scaling options: a physical server and a regional platform. If adding computing power becomes more difficult as the volume increases in the first case, you can do so in the cloud without unnecessary costs and complications. Advantages of Cloud Linux Scalability: Ability to increase server capacity at any time Resource customization depending on business needs Minimization of equipment costs Reduction of time for implementing new functions Capability to work with large volumes of data The privilege of Cloud Linux is that, despite the increased traffic, the system continues to work effectively at the required speed without failures or overloads. Thus, online store owners can be confident in the reliability of their platform even during peak loads. Ease of Management and Security The most critical aspects for online store owners are ease of management and high security. Cloud Linux offers flexible administration options and robust data protection tools. The system actively uses isolation and attack defense technologies to ensure the security of business and customer data. Cloud Linux can help improve security and ease of management in the following ways: Isolation of accounts and processes to prevent attacks Automatic updates and patches to avoid vulnerabilities Protection against DDoS attacks Reliable management of passwords and access rights Integration with anti-fraud systems to protect payments The Cloud Linux safe system provides more security guarantees than traditional solutions. Such features are essential for online stores, which often face fraud or data leakage threats. To use it, you need to set the proper settings. Save Your Budget with Cloud Linux Many online store owners are looking for savings. Traditional servers require significant investments in equipment, labor costs, and regular maintenance. However, Cloud Linux saves a lot on IT infrastructure and support personnel. The cloud technology platform works on a subscription model. You can more flexibly control your expenses by paying only for the features you use. Savings are available in the following methods: There’s no need for significant investments in physical equipment Reduced energy and maintenance costs Flexibility in choosing tariff plans Optimization of resource use No need for constant support The right approach to using Cloud Linux in an online store will allow you to save money greatly. This is excellent news because you can direct the saved budget to business development, marketing, improving customer service, and other areas. Final Thoughts Cloud Linux is the preferred solution for online retailers. The solution has a lot of strengths, including excellent security, required performance, flexibility, and scalability. The system has a particular appeal for companies because it is economical and easy to use. By leveraging Cloud Linux, businesses can ensure seamless operations even during peak traffic periods while maintaining robust security and cost-efficiency. The ability to scale resources efficiently provides online store owners with long-term stability and adaptability to market changes. You need to correctly select the host of your business. Investigate the options and find the best offer that will optimize the operation and maximize the returns. . Among the many options, cloud Linux can be called the ideal solution. This operating system provides. online, stores,essential, modern, economy, their, stability, speed, security. . MaK Ulac

Calendar 2 Feb 26, 2025 User Avatar MaK Ulac Server Security
78

Red Hat Enterprise Virtualization 2.2 Enhances Scalability and Security

Linux giant Red Hat is moving the ball forward on its mission of becoming a key virtualization and cloud infrastructure player. To that end, the company has announced the latest release of its Enterprise Virtualization hypervisor, version 2.2.. With this latest release, Red Hat said it has updated the virtualization platform to include new scalabilities, migration tools, and additional features to expand on performance and security. Version 2.2 also brings Red Hat technology into the world of desktops. With its Red Hat Enterprise Virtualization (RHEV) solution, Red Hat is on a mission to increase scalability and quickly catch up to the competition, which has quite a few more years on the company at this point. With RHEV 2.2, Red Hat has turned up the scalability dial by doubling the number of virtual CPUs that it can support in a single virtual machine from 8 to 16. The addressable amount of memory by a virtual machine has been quadrupled from 64GB to 256GB since the RHEV 2.1 release. The link for this article located at InfoWorld is no longer available. . Explore how Red Hat Enterprise Virtualization 2.2 boosts performance, scalability, and security for your virtualization needs.. Red Hat Enterprise Virtualization,RHEV 2.2,Cloud Infrastructure,Performance Enhancements. . LinuxSecurity.com Team

Calendar 2 Jun 25, 2010 User Avatar LinuxSecurity.com Team Vendors/Products
74

Understanding IaaS and PaaS Security in Cloud Ecosystems

OWASP AppSec DC 2009 had a compelling session that defined cloud taxonomies and the security implications associated with the cloud computing. The three taxonomies that have become part of our vernacular are: 1. Infrastructure as a Service (IaaS): Set of virtualized components that can be assembled to build a application. Amazon EC2, Rackspace, Opsource, and GoGrid are examples of IaaS where you can rent "virtual" hardware and software as a "pay-as-you-go" services. If you need 5 Linux servers running MySQL Database for 3 months, you'd subscribe to an IaaS provider and using their REST or Web service-based API (or command line if you're too cool) to provision, de-provision and monitor your instance.. 2. Platform as a Service (PaaS): A runtime environment for application developer to deploy their applications in their desired programming environments with production issues such as scalability, security and reliability already addressed by the Platform. Google App Engine, the support Java and Python is a good example of PaaS. Using PaaS developers can code applications locally on developer machines and push them to the cloud. The developed applications can automatically scale to millions of invocations and thousands of users. The developers do not have to concern themselves with managing threading, concurrency and load balancing issues for such almost unbound scalability. The link for this article located at AjaxWorld is no longer available. . 2. Platform as a Service (PaaS): A runtime environment for application developer to deploy their app. owasp, appsec, compelling, session, defined, cloud, taxonomies, security, implica. . Alex

Calendar 2 Dec 30, 2009 User Avatar Alex Network Security
78

Enhancing Security and Scalability in Backup Solutions with Amanda 2.5

Amanda is the world's most popular open source backup and recovery software. Amanda allows system administrators to set up a single server to back up multiple hosts to a tape- or disk-based storage system over the network. It uses native dump and/or GNU tar facilities and can back up a large number of workstations or servers running various versions of Linux, Unix, Mac OS-X or Microsoft Windows operating systems. On March 23rd, 2006, the Amanda team released a major version (2.5) of the software. Overall the focus of the release is on security of the backup process & backed up data, scalability of the backup process and ease of installation & configuration of Amanda. . Recently security of the backup process has been a hotly discussed topic. Encryption of data across the network as well as while being stored on backup media is critical for privacy concerns and compliance requirements. New security features in Amanda 2.5 help administrators to address these issues. Amanda 2.5 brings additional support for Kerberos 4/5 and OpenSSH. This allows Amanda to protect the transfer of data between clients and backup server with strong authentication- and authorization-mechanisms. The new release also features an abstracted secure communication API that will allow developers to easily add different communication plugins between backup server and client. The link for this article located at Amanda is no longer available. . Tagline 2.5 enhances data protection with upgraded encryption protocols and increased flexibility for network administrators.. Open Source Backup, Backup Security, Data Encryption, Scalability Options. . LinuxSecurity.com Team

Calendar 2 Mar 27, 2006 User Avatar LinuxSecurity.com Team Vendors/Products
74

Building A Security Architecture For Adaptive Enterprises

Volatility and immaturity in security technology will continue to make enterprisewide technology architectures impractical through 2003. However, the need for a consistent approach, scalability, agility, and auditability will drive development of adaptive, top-down security architectures encompassing consistent policy frameworks, strong process . . . . Volatility and immaturity in security technology will continue to make enterprisewide technology architectures impractical through 2003. However, the need for a consistent approach, scalability, agility, and auditability will drive development of adaptive, top-down security architectures encompassing consistent policy frameworks, strong process orientation, service definitions, formal roles/responsibilities, and domain-specific technology standards (2002-03). Scalable technology architectures for security will evolve as a result of broader standards (2004-06). The link for this article located at ZDNet is no longer available. . Volatility and immaturity in security technology will continue to make enterprisewide technology arc. technology, volatility, immaturity, security, continue, enterprisewide. . Anthony Pell

Calendar 2 Nov 13, 2002 User Avatar Anthony Pell Network Security
77

Debian: Security Build Management Improvements and Automation

"So, there's probably a whole bunch of people out there who're interested in the form new security infrastructure will take. So, what's the solution? Converting security.debian.org to be run by katie [and] Modifiying the central wanna-build infrastructure to do "Accepted-Autobuilding". Read more below.. . . . "So, there's probably a whole bunch of people out there who're interested in the form new security infrastructure will take. So, what's the solution? Converting security.debian.org to be run by katie [and] Modifiying the central wanna-build infrastructure to do "Accepted-Autobuilding". Read more below. From: Anthony Towns To: This email address is being protected from spambots. You need JavaScript enabled to view it. Subject: The New Security Build Infrastructure Date: Sat, 8 Jun 2002 18:26:46 +1000 Hello world, So, there's probably a whole bunch of people out there who're interested in the form new security infrastructure will take. If you're not, feel free to skip this message. Historically, which is to say, currently, the security.debian.org archive has been managed pretty manually: a member of the security team will patch a program with a security bug and test it; then ssh to machines of each different architecture in the stable release and build the new source there; then, once this is done everywhere, prepare an advisory including the md5sums of all the newly built packages; then move the packages into the appropriate place on security.debian.org; then run dpkg-scanpackages and dpkg-scansources; and, finally, sign and send out the advisory. (The above is the general idea aiui, anyway. I'm sure if anyone cares the security team can correct the details) This has a whole bunch of problems: since almost everything's done by hand, it's easy to forget to do something or to make mistakes, and this has occasionally resulted in broken security updates or confusing advisories. Additionally, it takes a lot of time and care, which can delay updates, and certainly makes the job a lot harder than it might otherwise be. But the real problem isit doesn't scale well: the ever growing number of packages alone gives the security team an ever increasing amount of work to do, with woody having twice the number of ports as potato we've made every single security update require twice as much effort from the security team, and that's just too much. Well, that's the problem statement anyway: managing security updates, and especially getting them built, needs to be much easier. So, what's the solution? For a fair while (at least a few months that I've been aware of), the security team were attempting to get "rbuilder" [0] installed on machines of each architecture so that they could use that to build security updates, but for various reasons didn't have much success. As such, in early to mid April, the buck was passed, although it wasn't for a couple of weeks after that that we figured out who it could reasonably be passed to. The new buildd infrastructure consists of two components that've been on the agenda for a while now: Converting security.debian.org to be run by katie Modifiying the central wanna-build infrastructure to do "Accepted-Autobuilding" For the former, the thought is that it's a waste to have all this neat software for managing Debian archives, and then not use it for our security archive -- but until now, nothing's been actually done, since making it happen requires some significant changes to both the security archive itself (poolising it amongst other things), and to generalise the katie code itself. Meanwhile, the latter is a nifty idea that the archive changes for crypto-in-main have allowed: since packages are checked (for signatures and such) within about fifteen minutes of them being uploaded, there's no longer any reason to have the autobuilders wait until the daily archive run before trying to build them. So it's basically a matter of setting up the buildds' sources.list to point to a new url [0], and add newly accepted packages to the wanna-build database, and -- presto chango! -- packages get automatically builtthirty minutes or an hour or so after they're uploaded! As it happens, there're a bunch of little complications beyond this, to the point where the current setup is the third reimplementation of the above basic description in the past month or so, but you get the idea. While the above makes for a good answer to the scalability problems the security team are facing -- the archive code and the autobuilders already cope with much larger numbers of packages than the security team produce -- there are a number of additional difficulties in trying to manage security uploads that have to be taken into account. The major difference is that security updates frequently shouldn't be made public as soon as they're ready; in some cases they only need to wait until they can be tested further or an advisory written, in others they need to wait for a week or more to avoid publicising the flaw until all vendors have had a reasonable chance to fix it. This is pretty much in direct opposition to the way normal uploads work: we want those to be publically available as soon as possible. And, of course, there's an additional problem here in that in order to do accepted autobuilding, packages need to be made available to the autobuilders as early as possible, which is well before thay should be made available to the wider public. So! How does it all work? Here's the general idea: a) Someone finds a security problem. b) Someone fixes the problem, and makes an upload to security.debian.org's incoming. That is to say, a package is uploaded to: security.debian.org:/org/security.debian.org/queue/unchecked (aka ) Its changelog needs to point it at "stable-security" or "testing-security" in place of the usual "unstable". It should be signed in the usual manner. It should, obviously, be tested fairly thoroughly. Anyone can do this, but presumably it'll usually be a member of the security team. If you're _not_ a member of the security team, you should definitely contact them before doing this. Further, whileanyone can upload files here, only the security team can see what people have uploaded. c) The upload gets checked and processed by "jennifer" and moved into queue/accepted, and the buildds are notified. Files in here can be accessed by the security team and (somewhat indirectly) by the buildds. d) Security-enabled buildds pick up the source package (prioritized over normal builds), build it, and send the logs to the security team. e) The security team reply to the logs, and the newly built packages are uploaded to queue/unchecked, where they're processed by jennifer, and moved into queue/accepted. f) When the security team are happy with the source package (ie, that it's been correctly built for all applicable architectures and that it fixes the security hole and doesn't introduce new problems of its own) they run a script (viz, "amber") which: installs the package into the security archive updates the Packages, Sources and Release files in the usual way sets up a template advisory that the security team can finish off (optionally) forwards the packages to the appropriate proposed-updates so that it can be included in the real archive ASAP And that's pretty much it. All of the above has been implemented and tested in one way or another, although some of this hasn't been in entirely realistic conditions yet. It does, though, seem pretty safe to say that any further changes that'll be needed will be small bugfixes rather than redesigns or rewrites. katie for security.debian.org has been setup on satie.debian.org [1] and basically works, and the buildd changes are being live tested on the alpha, i386, powerpc and sparc autobuilders. Credit for the katie implementation work go to James Troup, for the buildd changes, Ryan Murray, and for all the -devel and other flamewars, yours truly. ;) What you can expect next is for the security infrastructure to move over to satie permanently and into the hands of the security team, and an update on all the otherthings that affect woody which have come up over the past month and a bit. It's possible that some of these changes will let us handle security updates in better ways in future (I'm hopeful it'll let us does security updates for testing in a more timely manner, eg), but that probably won't become clear until the security team's had more of a chance to get comfortable with it all. Cheers, aj (woody release manager) [0] , as it happens. These are IP/password restricted and shouldn't be used except by autobuilders. If you want to poke around just for curiousity's sake, auric:/org/incoming.debian.org/ is one place to start. [1] Also accessible via a reference to this project's codename, "security by obscurity", as obscurity.debian.org. -- Anthony Towns . Explore the evolution of Debian's security framework, emphasizing enhancements to security update processes and system management for improved infrastructure and resilience. Debian Security Updates, Build Management, Auto-Build Infrastructure. . LinuxSecurity.com Team

Calendar 2 Jun 13, 2002 User Avatar LinuxSecurity.com Team Server Security
News Add Esm H340

Get the latest News and Insights

Get the latest Linux and open source security news straight to your inbox.

Community Poll

What got you started with Linux?

No answer selected. Please try again.
Please select either existing option or enter your own, however not both.
Please select minimum {0} answer(s).
Please select maximum {0} answer(s).
/main-polls/150-what-got-you-started-with-linux?task=poll.vote&format=json
150
radio
0
[{"id":483,"title":"Self-taught through trial and error","votes":545,"type":"x","order":1,"pct":78.42,"resources":[]},{"id":484,"title":"Formal training or courses","votes":30,"type":"x","order":2,"pct":4.32,"resources":[]},{"id":485,"title":"A job that required it","votes":34,"type":"x","order":3,"pct":4.89,"resources":[]},{"id":486,"title":"Other","votes":86,"type":"x","order":4,"pct":12.37,"resources":[]}] ["#ff5b00","#4ac0f2","#b80028","#eef66c","#60bb22","#b96a9a","#62c2cc"] ["rgba(255,91,0,0.7)","rgba(74,192,242,0.7)","rgba(184,0,40,0.7)","rgba(238,246,108,0.7)","rgba(96,187,34,0.7)","rgba(185,106,154,0.7)","rgba(98,194,204,0.7)"] 350
bottom 200
Your message here